This is because Undertow is testing SPDY and HTTP2, which use Jetty
ALPN. This jar resides on the boot class path, and you need to use a
specific version of it for a given JVM.
Undertow uses profiles to select between JDK 7 and 8, however it looks
like it will attempt to use the 8 jar if you test on 9. I will look at
updating the build to just ignore these tests if the appropriate version
of the ALPN jar is not available.
Stuart
Bernd Eckenfels wrote:
Hello JDK security team,
(cced the Undertow guys cause I mentioned this on the IRC channel)
when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot
of tests fail with the same "NosuchMethodError", and I am not sure why.
It looks like an internal inconsitency in the JSSE? However I tries the simple
SSLEngine demo code and that one compiles and runs.
Undertow master 79daf29
https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd959f6d0a7a5de
maven 3.2.3 Windows x64 7
this is using xnio-api and xnio-nio 3.3.0.Beta3 (from
jboss-public-repository-group)
One of the observed exceptions (but not related to SPDY IMHO):
03:26:29,211 ERROR (XNIO-1 I/O-2) [org.xnio.listener]<ChannelListeners.java:94>
XNIO001007: A channel event listener threw an exception:
java.lang.NoSuchMethodError:
sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String;
at
sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294)
at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972)
at
sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728)
at
sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750)
at
org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177)
at
org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85)
at
io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222)
at
io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132)
at
io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49)
at
io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123)
at
io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283)
at
org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
As xnio (the NIO abstraction used by undertow) uses asm and some
unsafe functions it might not be the cleanest test, however the
stacktrace looks like the problem is all inside javax.ssl / JSSE?
I am not sure where to look for the right JDK source version, is this before or
after the modular split? The latest code does not seem to match the stacktrace:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java
Gruss
Bernd
_______________________________________________
undertow-dev mailing list
undertow-...@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
