Search code examples
dockerintellij-ideawildflyremote-debugging

Remote debug docker+wildfly with intelliJ 2017.2.6


So there are a lot of posts around this subject, but none of which seems to help.

I have an application running on a wildfly server inside a docker container. And for some reason I cannot connect my remote debugger to it.

So, it is a wildfly 11 server that has been started with this command:

/opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0 -c standalone.xml --debug 9999;

And in my standalone.xml I have this:

<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>

The console output seems promising: Listening for transport dt_socket at address: 9999

I can even access the admin console with the credentials admin:admin on localhost:9990/console

However IntelliJ refuses to connect... I've creates a remote JBoss Server configuration that in the server tab points to localhost with management port 9990. And in the startup/connection tab I've entered 9999 as remote socket port.

The docker image has exposed the ports 9999 and 9990, and the docker-compose file binds those ports as is.

Even with all of this IntelliJ throws this message when trying to connect:

Error running 'remote':
Unable to open debugger port (localhost:9999): java.io.IOException "handshake failed - connection prematurally closed"

followed by

Error running 'remote':
Unable to connect to the localhost:9990, reason:
com.intellij.javaee.process.common.WrappedException: java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed

I'm completely lost as to what the issue might be...

Interessting addition is that after intelliJ fails, if I invalidate caches and restart then wildfly reprints the message saying that it is listening on port 9999


Solution

  • Not sure if this can be seen as an answer since it goes around the problem. But the way I solved this, was by adding a "pure" remote configuration in intelliJ instead of jboss remote. This means that it won't automagically deploy, but I'm fine with that