[undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE

[Stuart Douglas]

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-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev