Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Oct 2, 2015 · 2 comments
Assignees
Labels
in: web type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 2, 2015

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:

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

Referenced from: commits 1b31d39

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 3, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 3, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web type: bug
Projects
None yet
Development

No branches or pull requests

2 participants