Re: [GUMP@vmgump-vm3]: Project tomcat-tc7.0.x-test-apr (in module tomcat-7.0.x) failed
On 23/09/17 00:50, Igal @ Lucee.org wrote: > To the administrator of these automated emails, > > On 9/22/2017 9:54 PM, Bill Barker wrote: >> To whom it may engage... >> This is an automated request, but not an unsolicited one. For >> more information please visit http://gump.apache.org/nagged.html, >> and/or contact the folk at gene...@gump.apache.org. > > I don't mind these automated emails since I willingly and consciously > subscribed to this mailing list, but can you please update the time on > your machine? The time on the machine is correct and NTP is configured and running to ensure that it remains correct. > The time of these emails is set to several hours in the future and so > these emails are always at the top when sorted by "most recent first", > making me (and others, I'm sure) miss newer emails because it looks like > these are the latest ones. I sort my email that way and have no such problems. I suggest you check the headers of the e-mails that appear out of order and / or the configuration of your e-mail client to investigate why emails appear out of order. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1809434 - in /tomcat/trunk: java/org/apache/juli/ClassLoaderLogManager.java webapps/docs/changelog.xml
Author: rjung
Date: Sat Sep 23 14:45:48 2017
New Revision: 1809434
URL: http://svn.apache.org/viewvc?rev=1809434&view=rev
Log:
Use the correct path when loading the JVM
logging.properties file for Java 9.
Modified:
tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java?rev=1809434&r1=1809433&r2=1809434&view=diff
==
--- tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java (original)
+++ tomcat/trunk/java/org/apache/juli/ClassLoaderLogManager.java Sat Sep 23
14:45:48 2017
@@ -50,9 +50,22 @@ import java.util.logging.Logger;
* Short configuration information will be sent to System.err.
*/
public class ClassLoaderLogManager extends LogManager {
+
+private static final boolean isJava9;
+
public static final String DEBUG_PROPERTY =
ClassLoaderLogManager.class.getName() + ".debug";
+static {
+Class c = null;
+try {
+c = Class.forName("java.lang.Runtime$Version");
+} catch (ClassNotFoundException e) {
+// Must be Java 8
+}
+isJava9 = c != null;
+}
+
private final class Cleaner extends Thread {
@Override
@@ -478,7 +491,8 @@ public class ClassLoaderLogManager exten
}
// Try the default JVM configuration
if (is == null) {
-File defaultFile = new File(new
File(System.getProperty("java.home"), "lib"),
+File defaultFile = new File(new
File(System.getProperty("java.home"),
+ isJava9 ? "conf" : "lib"),
"logging.properties");
try {
is = new FileInputStream(defaultFile);
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1809434&r1=1809433&r2=1809434&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Sat Sep 23 14:45:48 2017
@@ -45,6 +45,14 @@
issues do not "pop up" wrt. others).
-->
+
+
+
+Use the correct path when loading the JVM
logging.properties
+file for Java 9. (rjung)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Java 9 TC shutdown warnings (reflection in WebappClassLoaderBase)
Hi all, when running TC 8.5.21 (9.0 should be the same) with Java 9 I get the following warnings on STDOUT during shutdown: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.catalina.loader.WebappClassLoaderBase (file:/.../lib/catalina.jar) to field java.lang.Thread.threadLocals WARNING: Please consider reporting this to the maintainers of org.apache.catalina.loader.WebappClassLoaderBase WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release If I add the mentioned flag, I get more such lines, all referring to org.apache.catalina.loader.WebappClassLoaderBase and then: field java.lang.Thread.threadLocals field java.lang.Thread.inheritableThreadLocals field java.lang.ThreadLocal$ThreadLocalMap.table method java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntries() field java.lang.ThreadLocal$ThreadLocalMap$Entry.value field sun.rmi.transport.Target.ccl field sun.rmi.transport.Target.stub field sun.rmi.transport.ObjectTable.objTable field sun.rmi.transport.ObjectTable.implTable Details may vary depending on the cleanup flags set in the loader, but this is 8.5 with default settings. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Java 9 TC shutdown warnings (reflection in WebappClassLoaderBase)
On 23/09/17 15:55, Rainer Jung wrote: > Hi all, > > when running TC 8.5.21 (9.0 should be the same) with Java 9 I get the > following warnings on STDOUT during shutdown: Tomcat 9 has the Java 9 fixes. 8.5.x doesn't. I've put together a list of the Java 9 commits that need to be back-ported. Now that Java 9 is final those back-ports need to happen. This is on my TODO list for after TomcatCon London on Tuesday. Mark > > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.catalina.loader.WebappClassLoaderBase > (file:/.../lib/catalina.jar) to field java.lang.Thread.threadLocals > WARNING: Please consider reporting this to the maintainers of > org.apache.catalina.loader.WebappClassLoaderBase > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > > > If I add the mentioned flag, I get more such lines, all referring to > org.apache.catalina.loader.WebappClassLoaderBase and then: > > field java.lang.Thread.threadLocals > field java.lang.Thread.inheritableThreadLocals > field java.lang.ThreadLocal$ThreadLocalMap.table > method java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntries() > field java.lang.ThreadLocal$ThreadLocalMap$Entry.value > field sun.rmi.transport.Target.ccl > field sun.rmi.transport.Target.stub > field sun.rmi.transport.ObjectTable.objTable > field sun.rmi.transport.ObjectTable.implTable > > Details may vary depending on the cleanup flags set in the loader, but > this is 8.5 with default settings. > > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: ClassLoaderLogManager.readConfiguration locates logging.properties incorrectly with JDK 9
Sorry about more than a year delay. I just ran into the same issue and found your mail. It should be fixed now by http://svn.apache.org/viewvc?rev=1809434&view=rev which will be part of TC 9.0.1. I also plan to backport this to TC 8.5 (at least). I have not chosen to do a Multi-Release jar but instead used a simple static check for Java 9. Regards, Rainer Am 28.07.2016 um 15:07 schrieb Chris Hegarty: Hi, The following exception can be seen when, running with JDK 9 b115 ( early access ) and shutting down the Tomcat server. The issue is that the code in org.apache.juli.ClassLoaderLogManager.readConfiguration() expects to find the ‘logging.properties' file in the ‘lib' directory of the JRE image. This is not the case in JDK 9, it has been moved to the ‘conf' directory of the image. See the "New run-time image structure” of JEP 220 [1] for details of this. The code can be simply updated to look in the ‘conf’ directory, or alternatively can select between ‘conf’ and ‘lib’ if required to run on multiple releases. Configuration error java.io.FileNotFoundException: /opt/jdk-9.jdk_b115/Contents/Home/lib/logging.properties (No such file or directory) at java.io.FileInputStream.open0(java.base@9-ea/Native Method) at java.io.FileInputStream.open(java.base@9-ea/FileInputStream.java:195) at java.io.FileInputStream.(java.base@9-ea/FileInputStream.java:138) at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:479) at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:402) at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:398) at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method) at org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:398) at org.apache.juli.ClassLoaderLogManager.addLogger(ClassLoaderLogManager.java:136) at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:507) at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:402) at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:398) at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method) at org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:398) at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:493) at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:309) at java.util.logging.LogManager.readPrimordialConfiguration(java.logging@9-ea/LogManager.java:437) at java.util.logging.LogManager.access$800(java.logging@9-ea/LogManager.java:156) at java.util.logging.LogManager$2.run(java.logging@9-ea/LogManager.java:387) at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method) at java.util.logging.LogManager.ensureLogManagerInitialized(java.logging@9-ea/LogManager.java:380) at java.util.logging.LogManager.getLogManager(java.logging@9-ea/LogManager.java:422) at java.util.logging.SimpleFormatter.getLoggingProperty(java.logging@9-ea/SimpleFormatter.java:63) at jdk.internal.logger.SimpleConsoleLogger$Formatting.getSimpleFormat(java.base@9-ea/SimpleConsoleLogger.java:491) at jdk.internal.logger.SurrogateLogger.getSimpleFormat(java.base@9-ea/SurrogateLogger.java:62) at java.util.logging.SimpleFormatter.(java.logging@9-ea/SimpleFormatter.java:67) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-ea/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base@9-ea/Constructor.java:453) at java.lang.Class.newInstance(java.base@9-ea/Class.java:550) at org.apache.juli.logging.DirectJDKLog.(DirectJDKLog.java:49) at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:115) at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:137) at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:188) at org.apache.catalina.startup.Bootstrap.(Bootstrap.java:52) -Chris. [1] http://openjdk.java.net/jeps/220 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Java 9 TC shutdown warnings (reflection in WebappClassLoaderBase)
Thanks Mark! You might also want to look at r1809434 as a candidate and check whether that workaround looks OK for you. Wishing you a nice and successful TomcatCon! Regards, Rainer Am 23.09.2017 um 17:01 schrieb Mark Thomas: On 23/09/17 15:55, Rainer Jung wrote: Hi all, when running TC 8.5.21 (9.0 should be the same) with Java 9 I get the following warnings on STDOUT during shutdown: Tomcat 9 has the Java 9 fixes. 8.5.x doesn't. I've put together a list of the Java 9 commits that need to be back-ported. Now that Java 9 is final those back-ports need to happen. This is on my TODO list for after TomcatCon London on Tuesday. Mark WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.catalina.loader.WebappClassLoaderBase (file:/.../lib/catalina.jar) to field java.lang.Thread.threadLocals WARNING: Please consider reporting this to the maintainers of org.apache.catalina.loader.WebappClassLoaderBase WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release If I add the mentioned flag, I get more such lines, all referring to org.apache.catalina.loader.WebappClassLoaderBase and then: field java.lang.Thread.threadLocals field java.lang.Thread.inheritableThreadLocals field java.lang.ThreadLocal$ThreadLocalMap.table method java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntries() field java.lang.ThreadLocal$ThreadLocalMap$Entry.value field sun.rmi.transport.Target.ccl field sun.rmi.transport.Target.stub field sun.rmi.transport.ObjectTable.objTable field sun.rmi.transport.ObjectTable.implTable Details may vary depending on the cleanup flags set in the loader, but this is 8.5 with default settings. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Java 9 TC shutdown warnings (reflection in WebappClassLoaderBase)
On 23/09/17 16:10, Rainer Jung wrote: > Thanks Mark! > > You might also want to look at r1809434 as a candidate and check whether > that workaround looks OK for you. Looks good to me. I've added to the list of J9 back-port candidates. It does beg the question whether or not we want to look at switching to multi-release JARs for all of the compatibility code. WDYT? > Wishing you a nice and successful TomcatCon! Thanks! Mark > > Regards, > > Rainer > > Am 23.09.2017 um 17:01 schrieb Mark Thomas: >> On 23/09/17 15:55, Rainer Jung wrote: >>> Hi all, >>> >>> when running TC 8.5.21 (9.0 should be the same) with Java 9 I get the >>> following warnings on STDOUT during shutdown: >> >> Tomcat 9 has the Java 9 fixes. 8.5.x doesn't. I've put together a list >> of the Java 9 commits that need to be back-ported. Now that Java 9 is >> final those back-ports need to happen. >> >> This is on my TODO list for after TomcatCon London on Tuesday. >> >> Mark >> >> >>> >>> WARNING: An illegal reflective access operation has occurred >>> WARNING: Illegal reflective access by >>> org.apache.catalina.loader.WebappClassLoaderBase >>> (file:/.../lib/catalina.jar) to field java.lang.Thread.threadLocals >>> WARNING: Please consider reporting this to the maintainers of >>> org.apache.catalina.loader.WebappClassLoaderBase >>> WARNING: Use --illegal-access=warn to enable warnings of further illegal >>> reflective access operations >>> WARNING: All illegal access operations will be denied in a future >>> release >>> >>> >>> If I add the mentioned flag, I get more such lines, all referring to >>> org.apache.catalina.loader.WebappClassLoaderBase and then: >>> >>> field java.lang.Thread.threadLocals >>> field java.lang.Thread.inheritableThreadLocals >>> field java.lang.ThreadLocal$ThreadLocalMap.table >>> method java.lang.ThreadLocal$ThreadLocalMap.expungeStaleEntries() >>> field java.lang.ThreadLocal$ThreadLocalMap$Entry.value >>> field sun.rmi.transport.Target.ccl >>> field sun.rmi.transport.Target.stub >>> field sun.rmi.transport.ObjectTable.objTable >>> field sun.rmi.transport.ObjectTable.implTable >>> >>> Details may vary depending on the cleanup flags set in the loader, but >>> this is 8.5 with default settings. >>> >>> Regards, >>> >>> Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Multi-release Jars [Was: Java 9 TC shutdown warnings (reflection in WebappClassLoaderBase)]
Am 23.09.2017 um 17:22 schrieb Mark Thomas:
On 23/09/17 16:10, Rainer Jung wrote:
Thanks Mark!
You might also want to look at r1809434 as a candidate and check whether
that workaround looks OK for you.
Looks good to me. I've added to the list of J9 back-port candidates. It
does beg the question whether or not we want to look at switching to
multi-release JARs for all of the compatibility code. WDYT?
Indeed, I ran my first multi-release Jar experiment (successfully)
today. For those who haven't yet seen it: starting with Java 9 one can
include instances of a class in a jar file that will only get used when
a specific JVM (major) version is detected at runtime. You can e.g. have
a default one as usual plus additional ones for specific Java runtime
versions. For Java 9 one would add a class at
META-INF/versions/9/org/apache/juli/... which would then be picked when
the runtime Java version is 9.
The enable the feature, one simply has to add the attribute
Multi-Release: true
to the Manifest file of the jar.
Thinks that come to my mind:
- you can have multiple versions of the same class. If we would use it
like that, we would have to slightly reorganize our svn layout to
reflect that, e.g. java/org/... plus new java9/org/
- accordingly we would need e.g. a directory output/classes9 or similar.
- If we need Java 9 for compilation of the Java 9 classes, we would
mimic the Java 7 lines from the TC 7 build.xml.
- To add the Java 9 classes to one of our jars it would suffice in
build.xml to do something like
- to reduce redundant maintenance it would be good to factor out JVM
dependent code, so that the classes we have to maintain multiply mostly
contain the code that's really version-dependent.
For instance when using the feature for my Java 9 change in Juli
http://svn.apache.org/viewvc?rev=1809434&view=rev one could use e.g. a
small but version dependent Constants.java which would provide the
correct directory name ("lib" versus "conf"). Or more easily a one line
properties file available in two versions providing the directory name.
I have not made any check on performance implications for the slightly
more complex class loading. What I did see, is that -verbose:class does
not indicate, which of the versions was chosen.
I currently do not have a real insight on how our most important JVM
version dependencies look. I guess how useful multi-release is, might
depend on the type of code dependencies we have.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Multi-release Jars [Was: Java 9 TC shutdown warnings (reflection in WebappClassLoaderBase)]
Forgot the reference: http://openjdk.java.net/jeps/238
Am 23.09.2017 um 20:01 schrieb Rainer Jung:
Am 23.09.2017 um 17:22 schrieb Mark Thomas:
On 23/09/17 16:10, Rainer Jung wrote:
Thanks Mark!
You might also want to look at r1809434 as a candidate and check whether
that workaround looks OK for you.
Looks good to me. I've added to the list of J9 back-port candidates. It
does beg the question whether or not we want to look at switching to
multi-release JARs for all of the compatibility code. WDYT?
Indeed, I ran my first multi-release Jar experiment (successfully)
today. For those who haven't yet seen it: starting with Java 9 one can
include instances of a class in a jar file that will only get used when
a specific JVM (major) version is detected at runtime. You can e.g. have
a default one as usual plus additional ones for specific Java runtime
versions. For Java 9 one would add a class at
META-INF/versions/9/org/apache/juli/... which would then be picked when
the runtime Java version is 9.
The enable the feature, one simply has to add the attribute
Multi-Release: true
to the Manifest file of the jar.
Thinks that come to my mind:
- you can have multiple versions of the same class. If we would use it
like that, we would have to slightly reorganize our svn layout to
reflect that, e.g. java/org/... plus new java9/org/
- accordingly we would need e.g. a directory output/classes9 or similar.
- If we need Java 9 for compilation of the Java 9 classes, we would
mimic the Java 7 lines from the TC 7 build.xml.
- To add the Java 9 classes to one of our jars it would suffice in
build.xml to do something like
- to reduce redundant maintenance it would be good to factor out JVM
dependent code, so that the classes we have to maintain multiply mostly
contain the code that's really version-dependent.
For instance when using the feature for my Java 9 change in Juli
http://svn.apache.org/viewvc?rev=1809434&view=rev one could use e.g. a
small but version dependent Constants.java which would provide the
correct directory name ("lib" versus "conf"). Or more easily a one line
properties file available in two versions providing the directory name.
I have not made any check on performance implications for the slightly
more complex class loading. What I did see, is that -verbose:class does
not indicate, which of the versions was chosen.
I currently do not have a real insight on how our most important JVM
version dependencies look. I guess how useful multi-release is, might
depend on the type of code dependencies we have.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump-vm3]: Project tomcat-tc7.0.x-validate (in module tomcat-7.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc7.0.x-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-validate : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump-vm3.apache.org/tomcat-7.0.x/tomcat-tc7.0.x-validate/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-validate.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-validate (Type: Build) Work ended in a state of : Failed Elapsed: 28 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbase.path=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-build-libs -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20170924.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.7-SNAPSHOT.jar:/srv/g ump/public/workspace/apache-commons/logging/target/commons-logging-20170924.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20170924.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-24.0-jre-SNAPSHOT.jar - [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/el/TestELInJsp.java:23: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/el/TestMethodExpressionImpl.java:30: Extra separation in import group before 'org.junit.Before' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/el/TestValueExpressionImpl.java:34: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/el/lang/TestELArithmetic.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/el/lang/TestELSupport.java:29: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/el/parser/TestELParser.java:28: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/jasper/compiler/TestAttributeParser.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/jasper/compiler/TestCompiler.java:28: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/jasper/compiler/TestGenerator.java:37: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/jasper/compiler/TestJspConfig.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-7.0.x/test/org/apache/jasper/compiler/TestParser.java:26: Extra sep
[GUMP@vmgump-vm3]: Project tomcat-tc8.0.x-validate (in module tomcat-8.0.x) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-tc8.0.x-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc8.0.x-validate : Tomcat 8.x, a web server implementing the Java Servlet 3.1, ... Full details are available at: http://vmgump-vm3.apache.org/tomcat-8.0.x/tomcat-tc8.0.x-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump-vm3.apache.org/tomcat-8.0.x/tomcat-tc8.0.x-validate/gump_work/build_tomcat-8.0.x_tomcat-tc8.0.x-validate.html Work Name: build_tomcat-8.0.x_tomcat-tc8.0.x-validate (Type: Build) Work ended in a state of : Failed Elapsed: 35 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbase.path=/srv/gump/public/workspace/tomcat-8.0.x/tomcat-build-libs -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-8.0.x] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20170924.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.7-SNAPSHOT.jar:/srv/g ump/public/workspace/apache-commons/logging/target/commons-logging-20170924.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20170924.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-24.0-jre-SNAPSHOT.jar - [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/el/TestValueExpressionImpl.java:34: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/el/lang/TestELArithmetic.java:26: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/el/lang/TestELSupport.java:30: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/el/parser/TestELParser.java:28: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/TestAttributeParser.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/TestCompiler.java:29: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/TestGenerator.java:36: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/TestJspConfig.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/TestParser.java:25: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/TestParserNoStrictWhitespace.java:26: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/jasper/compiler/Tes
[GUMP@vmgump-vm3]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate : Tomcat 9.x, a web server implementing the Java Servlet 4.0, ... Full details are available at: http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 37 secs Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-8.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20170924.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/commons-cli/target/commons-cli-1.5-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.7-SNAPSHOT.jar:/srv/g ump/public/workspace/apache-commons/logging/target/commons-logging-20170924.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20170924.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-24.0-jre-SNAPSHOT.jar - [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/TestValueExpressionImpl.java:34: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/lang/TestELArithmetic.java:26: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/lang/TestELSupport.java:30: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/el/parser/TestELParser.java:30: Extra separation in import group before 'org.junit.Ignore' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestAttributeParser.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestCompiler.java:29: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestGenerator.java:36: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestJspConfig.java:24: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestParser.java:25: Extra separation in import group before 'org.junit.Assert' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestParserNoStrictWhitespace.java:26: Extra separation in import group before 'org.junit.Test' [ImportOrder] [checkstyle] [ERROR] /srv/gump/public/workspace/tomcat-trunk/test/org/apache/jasper/compiler/TestScriptingV
