-
Bug
-
Resolution: Not A Defect
-
Blocker
-
None
-
Windows 7 SP1, 64-bit (Jenkins as Windows Service)
Jenkins 2.54 (Updated from 2.53)
Java 1.8.0 121-b13
After updating from Jenkins 2.53 to Jenkins 2.54 the Windows service appears to start successfully but the error log reports an InvocationTargetException caused by an UnsupportedClassVersionError: jenkins/util/SystemProperties : Unsupported major.minor version 52.0
Navigating to the Jenkins homepage gives an error code 503.
Reverting to Jenkins 2.53 fixes the issue.
The jenkins.err file is attached, but the stack trace is as follows:
WARNING: Failed startup of context w.@68be28{/,file:/C:/Program%20Files%20(x86)/Jenkins/war/,STARTING}{C:\Program Files (x86)\Jenkins\war}
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.webapp.IterativeDescriptorProcessor.visit(IterativeDescriptorProcessor.java:85)
at org.eclipse.jetty.webapp.IterativeDescriptorProcessor.process(IterativeDescriptorProcessor.java:72)
at org.eclipse.jetty.webapp.MetaData.resolve(MetaData.java:408)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1340)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.server.Server.start(Server.java:387)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.Server.doStart(Server.java:354)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at winstone.Launcher.<init>(Launcher.java:152)
at winstone.Launcher.main(Launcher.java:352)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main._main(Main.java:264)
at Main.main(Main.java:112)
Caused by: java.lang.UnsupportedClassVersionError: jenkins/util/SystemProperties : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at org.eclipse.jetty.webapp.WebAppClassLoader.findClass(WebAppClassLoader.java:510)
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:441)
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:403)
at org.eclipse.jetty.server.handler.ContextHandler.loadClass(ContextHandler.java:1583)
at org.eclipse.jetty.webapp.StandardDescriptorProcessor.visitListener(StandardDescriptorProcessor.java:1956)
... 25 more
Our jenkins.xml configuration file is also attached.
- is duplicated by
-
-
- Resolved
-
- is related to
-
-
- Resolved
-
[JENKINS-43492] Jenkins 2.54 causes java.lang.UnsupportedClassVersionError
Ciaran McCarthy
created issue -
Jenkins 2.54 updates the minimal Java requirement to Java 8. It has been announced multiple times in Jenkins blogs and the mailing list. Here is the last entry: https://jenkins.io/blog/2017/04/10/jenkins-has-upgraded-to-java-8/
Even though the "Environment" field says it is Java 8, version "52" means that the JDK you are running on is not compatible with the Java SE 8 standard.
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Ciaran McCarthy
added a comment - I think we've figured it out.
When we first started using Jenkins we installed it using the Windows installer, which installed Jenkins as a service. This installed its own version of Java as well and it has been using that all this time to run Jenkins:
"C:\Program Files (x86)\Jenkins\jre\bin\java.exe" -version java version "1.7.0_25" Java(TM) SE Runtime Environment (build 1.7.0_25-b17) Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode)
This was a bit of a surprise for us - we'd been updating Java regularly, the "java -version" command gave us version 8, and we never realised that Jenkins was using its own version of Java. I think that this is why Jenkins 2.54 was failing even though we had Java version 8 installed on our server.
Since the issue is not with Jenkins itself I am satisfied that this issue is "Not a defect". Though I am a bit concerned that if Jenkins from the Windows Installer is using its own version of Java it could leave a security hole. Maybe this is something that's worth looking into?
Thanks for pointing us in the right direction Oleg, we really appreciate your help and patience! 
Ciaran McCarthy
added a comment - I think we've figured it out.
When we first started using Jenkins we installed it using the Windows installer, which installed Jenkins as a service. This installed its own version of Java as well and it has been using that all this time to run Jenkins:
"C:\Program Files (x86)\Jenkins\jre\bin\java.exe" -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode)
This was a bit of a surprise for us - we'd been updating Java regularly, the "java -version" command gave us version 8, and we never realised that Jenkins was using its own version of Java. I think that this is why Jenkins 2.54 was failing even though we had Java version 8 installed on our server.
Since the issue is not with Jenkins itself I am satisfied that this issue is "Not a defect". Though I am a bit concerned that if Jenkins from the Windows Installer is using its own version of Java it could leave a security hole. Maybe this is something that's worth looking into?
Thanks for pointing us in the right direction Oleg, we really appreciate your help and patience! | Link |
New:
This issue is related to |
| Epic Link |
New:
|
similar problem on debian linux: jenkins.war does not start inside tomcat, and shows the log:
INFORMATION: Deploying web application archive /data/jenkins/webapps/jenkins.war
Apr 11, 2017 8:34:18 AM org.apache.catalina.deploy.WebXml setVersion
WARNUNG: Unknown version string [3.1]. Default version will be used.
Apr 11, 2017 8:34:20 AM org.apache.catalina.startup.ContextConfig validateSecurityRoles
WARNUNG: Security role name ** used in an <auth-constraint> without being defined in a <security-role>
Apr 11, 2017 8:34:21 AM org.apache.catalina.startup.TldConfig execute
INFORMATION: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs
were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
Apr 11, 2017 8:34:21 AM org.apache.catalina.core.StandardContext startInternal
SCHWERWIEGEND: One or more listeners failed to start. Full details will be found in the appropriate container log file
Apr 11, 2017 8:34:21 AM org.apache.catalina.core.StandardContext startInternal
SCHWERWIEGEND: Context [/jenkins] startup failed due to previous errors
Reverting to 2.53 fixed the problem