-
Bug
-
Resolution: Fixed
-
Critical
-
Windows Server 2012
This is broken since 2.128 there was an upgrade to winstone and thus jetty to version 9.4.8 but jetty changed the loading to use a service loader mechanism provided by the classpath. Since jenkins default installation is using the -jar command there is no way to pass the Service jar files to the command line of jenkins. -jar command line ignores any other jars provided using -classpath. Additionally these can't be passed using -Xbootclasspath either as they throw a ClassNotFoundException for the jetty.ssl classes.
This is what happens by default now:
java.lang.IllegalStateException: No Server ALPNProcessors!java.lang.IllegalStateException: No Server ALPNProcessors! at org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.<init>(ALPNServerConnectionFactory.java:53) at winstone.Http2ConnectorFactory.start(Http2ConnectorFactory.java:77) at winstone.Launcher.spawnListener(Launcher.java:216) at winstone.Launcher.<init>(Launcher.java:154) at winstone.Launcher.main(Launcher.java:363) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at Main._main(Main.java:344) at Main.main(Main.java:160)
If you pass the jetty-alpn-openjdk8-server-9.4.11.v20180605.jar into the Xbootclasspath as well as the alpn jar you get this:
WARNING: Failed to start ALPNWARNING: Failed to start ALPNjava.lang.IllegalStateException: No Server ALPNProcessors! at org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.<init>(ALPNServerConnectionFactory.java:53) at winstone.Http2ConnectorFactory.start(Http2ConnectorFactory.java:77) at winstone.Launcher.spawnListener(Launcher.java:216) at winstone.Launcher.<init>(Launcher.java:154) at winstone.Launcher.main(Launcher.java:363) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at Main._main(Main.java:344) at Main.main(Main.java:160) Suppressed: java.lang.NoClassDefFoundError: org/eclipse/jetty/io/ssl/ALPNProcessor$Server at java.lang.ClassLoader.findBootstrapClass(Native Method) at java.lang.ClassLoader.findBootstrapClassOrNull(ClassLoader.java:1015) at java.lang.ClassLoader.loadClass(ClassLoader.java:413) at java.lang.ClassLoader.loadClass(ClassLoader.java:411) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:411) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.<init>(ALPNServerConnectionFactory.java:60) ... 10 more
Trying to use conscrypt using the jar file in the bootclasspath is also a non starter due to the previous issue. Also can't pass the command line --add-to-start=conscrypt since that is not available in winstone. There is a possibility winstone can use the common URLClassLoader for loading the server classes but that is not what is happening. winstone initializes the Common ClassLoader before the listeners but doesn't do anything with it until after the listeners are started.
- relates to
-
JENKINS-45438 HTTP/2 Support
- Closed