java.lang.NoClassDefFoundError - Undertow request failed HttpServerExchange - Could not initialize class org.xnio.channels.Channels

Communities CommandBox CLI
1

When attempting to browse to any file in the webroots of a started server, I get a blank response from the server. I am also unable to hit the admin page of the lucee/ACF/railo server. I can telnet to the TCP port the server is listening on, but can not GET any documents. CommandBox was working wonderfully only a few weeks ago and I’ve been using it since 2.x. This problem started sometime after updating to version 3.2, although I’m not sure if the upgrade was the direct cause of the issue. I’ve blown my .commandBox directory away several times and tried other versions of commandbox, going back as far as 3.0.1, all give the same results. I also tried the version that comes with the JRE bundled.

The issue seems to be related to Undertow and the lib/runwar-3.4.5.jar file. Hopefully, it’s something simple that I’ve overlooked. It’s driving me crazy at this point.

here’s the stack trace

2016-09-29 14:18:39 ERROR io.undertow.request UT005071: Undertow request failed HttpServerExchange{ GET / request {Connection=[keep-alive], Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8], Accept-Language=[en-US,en;q=0.8], Cache-Control=[max-age=0], Accept-Encoding=[gzip, deflate, sdch], User-Agent=[Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36], Upgrade-Insecure-Requests=[1], Host=[localhost:8081]} response {Connection=[keep-alive], Last-Modified=[Mon, 26 Sep 2016 22:14:40 GMT], Content-Type=[text/html], Content-Length=[58], Accept-Ranges=[bytes], Date=[Thu, 29 Sep 2016 20:18:39 GMT]}}
java.lang.NoClassDefFoundError: Could not initialize class org.xnio.channels.Channels
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:609)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:478)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:561)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:332)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Exception in thread “XNIO-1 task-13” java.lang.NoClassDefFoundError: Could not initialize class org.xnio.channels.Channels
at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:170)
at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:246)
at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:612)
at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:89)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1576)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:226)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2016-09-29 14:18:45 ERROR io.undertow.request UT005023: Exception handling request to /
java.lang.NoClassDefFoundError: Could not initialize class org.xnio.channels.Channels
at io.undertow.servlet.spec.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:287)
at io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:194)
at io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:187)
at io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:63)
at io.undertow.server.handlers.resource.PathResource$1ServerTask.run(PathResource.java:178)
at io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:247)
at io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:105)
at io.undertow.servlet.handlers.DefaultServlet.serveFileBlocking(DefaultServlet.java:332)
at io.undertow.servlet.handlers.DefaultServlet.doGet(DefaultServlet.java:180)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

and output of ‘info’ command. (although I have the same problem regardless of the version of commandBox I use)

CommandBox Version: 3.2.0+00397
CFML Engine: Lucee
CFML Version: 4.5.2.018 final (Neo)
Java Version: 1.8.0_101 (Oracle Corporation)
Authors: Brad Wood, Luis Majano, Denny Valiant

2

Seems a lot like a JRE path problem. Is it possible there is more than
one JRE in the environment path?

I'd think using the one with the bundled JRE would work, and the output
from the info command is listing a JRE which should work, but I'm pretty
sure that error (and the fact that you're seeing it with so many things
you've tried) relates to the JRE being used...

Maybe take a look at what's in your path-- Are you on Windows? You
might try "where java" from the windows command prompt, just to see if
there's more than one or some such.

Denny

3

Denny, thanks for the reply. Are you referring to the windows environment variable “path”? (or java classpath?)

Here’s more info. I set my path so it only includes the path to the java /bin folder. Still seeing same results. I thought it was a JRE issue as well, but using the JRE version from the download page would rule that out, right?
`

CommandBox:commandbox-win-3.2.0> !echo %path%
C:\Program Files\Java\jre1.8.0_101\bin;C:\Program Files\Java\jre1.8.0_101\bin
CommandBox:commandbox-win-3.2.0> !java -version
CommandBox:commandbox-win-3.2.0> !java -version
java version “1.8.0_101”
Java™ SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot™ 64-Bit Server VM (build 25.101-b13, mixed mode)
CommandBox:commandbox-win-3.2.0> server cd test

cd “C:\webroots\test”
C:\webroots\test
CommandBox:test> server show
{

}
CommandBox:test> server start debug=10
Looking for server JSON file by convention: C:\webroots\test/server.json
webroot defaulted to location of server’s JSON file: C:\webroots\test
start server in - C:\webroots\test
server name - test
server config file - C:\webroots\test/server.json
Server start command: “C:\Program Files\Java\jre1.8.0_101\bin\java.exe”
-Xmx512m
-Xms512m
-javaagent:“C:\Users\joel.clegg.CommandBox/lib/lucee-inst.jar”
-jar “C:\Users\joel.clegg.CommandBox\lib\runwar-3.4.5.jar”
–background=true
–port 51647
–host 127.0.0.1
–debug=10
–stop-port 49486
–processname “test [lucee 4.5.2.018]”
–log-dir “C:\Users\joel.clegg.CommandBox/server/AFEC345C7EBC6F204B58992CF6909C60-test/lucee-4.5.2.018/logs”
–open-browser true
–open-url http://127.0.0.1:51647
–cfengine-name “lucee”
–server-name “test”
–tray-icon “C:\Users\joel.clegg.CommandBox\cfml\system\config\server-icons\trayicon-lucee-32px.png”
–tray-config “C:\Users\joel.clegg.CommandBox/lib/traymenu-lucee.json”
–directoryindex “true”
–cfml-web-config “C:\Users\joel.clegg.CommandBox/server/AFEC345C7EBC6F204B58992CF6909C60-test/lucee-4.5.2.018”
–cfml-server-config “C:\Users\joel.clegg.CommandBox/engine/cfml/server/”
–timeout 120
-war “C:\webroots\test”
–lib-dirs “C:\Users\joel.clegg.CommandBox/lib”
–urlrewrite-enable false
The server for C:\webroots\test is starting on 127.0.0.1:51647… type ‘server status’ to see result
CommandBox:test>

`

Still not getting any love after the server starts. That’s what led me to believe it must be an Undertow issue. All my google searches seem to indicate it might be an issue with classpath and lingering JREs.

4

And here’s the output when I use the JRE bundled version of commandbox 3.2: I get the exact same results with this as I do with the standalone version. It happens when I use Chrome, FF or IE11, (it’s windows 7 64 bit)

`

CommandBox:commandbox-jre-win64-3.2.0> !echo %path%
C:\Program Files\Java\jre1.8.0_101\bin;C:\Users\joel.clegg\Downloads\commandbox-jre-win64-3.2.0.\jre\bin
CommandBox:commandbox-jre-win64-3.2.0> !java -version
java version “1.8.0_101”
Java™ SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot™ 64-Bit Server VM (build 25.101-b13, mixed mode)
CommandBox:commandbox-jre-win64-3.2.0> server cd test

cd “C:\webroots\test”
C:\webroots\test
CommandBox:test> server show
{

}
CommandBox:test> server start debug=10
Looking for server JSON file by convention: C:\webroots\test/server.json
webroot defaulted to location of server’s JSON file: C:\webroots\test
start server in - C:\webroots\test
server name - test
server config file - C:\webroots\test/server.json
Server start command: C:\Users\joel.clegg\Downloads\commandbox-jre-win64-3.2.0\jre\bin\java.exe
-Xmx512m
-Xms512m
-javaagent:“C:\Users\joel.clegg.CommandBox/lib/lucee-inst.jar”
-jar “C:\Users\joel.clegg.CommandBox\lib\runwar-3.4.5.jar”
–background=true
–port 51647
–host 127.0.0.1
–debug=10
–stop-port 49834
–processname “test [lucee 4.5.2.018]”
–log-dir “C:\Users\joel.clegg.CommandBox/server/AFEC345C7EBC6F204B58992CF6909C60-test/lucee-4.5.2.018/logs”
–open-browser true
–open-url http://127.0.0.1:51647
–cfengine-name “lucee”
–server-name “test”
–tray-icon “C:\Users\joel.clegg.CommandBox\cfml\system\config\server-icons\trayicon-lucee-32px.png”
–tray-config “C:\Users\joel.clegg.CommandBox/lib/traymenu-lucee.json”
–directoryindex “true”
–cfml-web-config “C:\Users\joel.clegg.CommandBox/server/AFEC345C7EBC6F204B58992CF6909C60-test/lucee-4.5.2.018”
–cfml-server-config “C:\Users\joel.clegg.CommandBox/engine/cfml/server/”
–timeout 120
-war “C:\webroots\test”
–lib-dirs “C:\Users\joel.clegg.CommandBox/lib”
–urlrewrite-enable false
The server for C:\webroots\test is starting on 127.0.0.1:51647… type ‘server status’ to see result
`

5

I FINALLY figured out my issue. I only figured it out after installing git and receiving an error about /dev/null not being avail. A little bit of googling led me to the windows device manager where there is a hidden, non-plug n play device named “Null”. For some reason, this device was disabled on my system. I enabled it and voila!

Commandbox and git both working as they should.

6

Woohoo!

Wow, that's really interesting. Thanks for reporting back what the
solution turned out to be! Some poor soul in the future will thank you.

In retrospect, grabbing that interface must have been wonky, so I wonder
if setting a specific host/port to listen on would have bypassed the
error...

Which is also weird, as I'd have expected some kind of null pointer
exception, versus a class not found one.

"troubleshooting-level : ELEVEN"
-Den

7

Oh man, if you only knew the things I've done to troubleshoot this issue. I thought of the host and listening port early on in this journey, unfortunately. I used to be a network engineer so my networking foo is quite strong. My java troubleshooting skills, however, not so much. Just to give you an idea of how badly this was driving me mad, here are just a few of the things i/we tried over the last few weeks. (After the obvious tshooting got me nowhere) :

1. I turned widows firewall logging up all the way and saw the traffic being allowed through. I disabled windows firewall altogether, just to be sure.
2. I worked with my IT dept to disable pieces of the kaspersky virus/Malware software we use, until all of the protection mechanisms were disabled and it still wasn't working. Still not fully convinced, I talked them into completely uninstalling the software on my laptop, temporarily of course, just to be sure it wasn't hijacking my connections.
3. At this point, I was completely baffled. I was so sure Kaspersky was going to be the culprit. I thought maybe runwar or undertow stored some settings in the windows registry or something, so I created a new windows user, downloaded Commandbox fresh and still had the issue.
4. Before all that, I uninstalled all my Javas and reinstalled only JRE 1.8.101. Tried 32 and 64 bit versions. But it didn't make sense that it was java to me.
5. I did a system restore back as far as I could go, July of 2016.

I was ready to reinstall windows but I thought surely there was another windows user who would run into the issue sooner or later. So I decided to give it a week or two.

I'm just glad my team decided to move away from SVN and move to git. I never would have found the disabled "Null" device driver had it not been for git refusing to load.

The only good thing that came from this fiasco is now I have a really evil way to mess with a coworker if s/he ever leaves her pc unlocked for any amount of time. (Unless she uses git, that is :grinning:) really though, I learned A TON about command box,runwar,java and undertow through all this. :grinning: that's a plus.

I can't tell you how great it is to see the directory structure of my server root appear in my browser now when I start a server in commandbox. It had been so long!

Take care and thanks again!