ClassNotFoundException: org.xnio.StreamConnection in Wildfly 10.0.0.CR2 [SPR-13529]

[spring-projects-issues]

Brian Clozel opened SPR-13529 and commented

While running integration tests with Wildfly 10.0.0.CR2, I noticed that websocket support was failing with:

15:00:57 [ServerService Thread Pool -- 13] DefaultSockJsService[WARN] - Failed to create a default WebSocketTransportHandler
java.lang.IllegalStateException: Failed to instantiate RequestUpgradeStrategy: org.springframework.web.socket.server.standard.UndertowRequestUpgradeStrategy
	at [...]
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)

Caused by: java.lang.IllegalStateException: Incompatible Undertow API version
	at org.springframework.web.socket.server.standard.UndertowRequestUpgradeStrategy.<clinit>(UndertowRequestUpgradeStrategy.java:129)
	... 57 more
Caused by: java.lang.NoClassDefFoundError: org/xnio/StreamConnection
	at org.springframework.web.socket.server.standard.UndertowRequestUpgradeStrategy.<clinit>(UndertowRequestUpgradeStrategy.java:125)
	... 57 more
Caused by: java.lang.ClassNotFoundException: org.xnio.StreamConnection from [Module "deployment.spring-websocket-portfolio.war:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
	... 58 more

Both undertow and xnio modules are properly loaded:

INFO  [org.xnio] (MSC service thread 1-7) XNIO version 3.3.2.Final
INFO  [org.xnio.nio] (MSC service thread 1-7) XNIO NIO Implementation Version 3.3.2.Final
INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0003: Undertow 1.3.0.CR2 starting
INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) WFLYUT0003: Undertow 1.3.0.CR2 starting

But it seems that the xnio module is not made available to the application classpath by default.

Digging into Wildfly class loading, I tried to add the following configuration in my test application pom.xml:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.2</version>
  <configuration>
    <failOnMissingWebXml>false</failOnMissingWebXml>
    <archive>
      <manifestEntries>
        <Dependencies>org.jboss.xnio</Dependencies>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>

This configuration asks Wildfly to make the org.jboss.xnio module available to the application classpath. And this workaround fixes the issue.

Is there a way to reflectively call undertow's Handshake.createChannel method without loading xnio's StreamConnection.class?

---

Issue Links:

• Compatibility with WildFly 10 [SPR-13477] #18056 Compatibility with WildFly 10 ("is depended on by")
• UndertowRequestUpgradeStrategy not compatible with WildFly anymore [SPR-13619] #18197 UndertowRequestUpgradeStrategy not compatible with WildFly anymore
• Make use of native doUpgrade operation in Undertow 1.3.5+ / 1.4 [SPR-13593] #18171 Make use of native doUpgrade operation in Undertow 1.3.5+ / 1.4

Referenced from: commits 1b31d39

[spring-projects-issues]

Juergen Hoeller commented

The problem here is that StreamConnection is a declared parameter type not only for the createChannel method but also for the HttpUpgradeListener.handleUpgrade method that we need to implement as a callback parameter to be passed to ServletWebSocketHttpExchange.upgradeChannel later on. Assuming that the class loader is equally restrictive there, we'd just fail at a later point then...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Hmm, we could implement the HttpUpgradeListener callback as a dynamic proxy, then we wouldn't have to refer to the StreamConnection type there either... After all, we just need to pass it on to the already reflective createChannel call as a plain Object. I'll try that tomorrow night; otherwise we'll be out of luck in any case :-(

Juergen