Cannot set Debug to work for Java via Dockerized WebLogic, not with intelliJ nor Studio Code

Question

I want to attach the Debugger to my deployed WARs in my dockerized WebLogic 12c. I use this official image of WebLogic (which is a Linux container) https://hub.docker.com/_/oracle-weblogic-server-12c and I start the container using docker command:

docker run -d -p 4002:4002 -p 9002:9002 
-v c:/my-path-to-shared-volume:/u01/oracle/properties 
-e ADMINISTRATION_PORT_ENABLED=true -e DOMAIN_NAME=docker_domain 
-e JAVA_TOOL_OPTIONS=\"-agentlib:jdwp=transport=dt_socket,address=4002,server=y,suspend=n\" 
--name weblogic store/oracle/weblogic:12.2.1.3-dev-200109

The weblogic console comes alive at https://localhost:9002/console/ but when trying to run the debugger, my IDE says:

Unable to open debugger port (localhost:4002): java.io.IOException "handshake failed - connection prematurally closed"

My OS is Windows10. I tried with Visual Studio Code and IntelliJ, and got the same output. The WARs run just fine and they respond when I use portman to hit some service endpoints.

What seems to happen is that weblogic start scripts inside the container tries to apply the Java Options param twice! Please see the relative parts of container output below:

Domain Home is: /u01/oracle/user_projects/domains/docker_domain Picked up JAVA_TOOL_OPTIONS: "-agentlib:jdwp=transport=dt_socket,address=localhost:4002,server=y,suspend=n" Listening for transport dt_socket at address: 4002 Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell

[...](and further down in the logs I get: )

Starting WLS with line: /usr/java/jdk-8/bin/java -server -Djava.security.egd=file:/dev/./urandom -cp /u01/oracle/wlserver/server/lib/weblogic-launcher.jar -Dlaunch.use.env.classpath=true -Dweblogic.Name=AdminServer -Djava.security.policy=/u01/oracle/wlserver/server/lib/weblogic.policy -Djava.system.class.loader=com.oracle.classloader.weblogic.LaunchClassLoader -javaagent:/u01/oracle/wlserver/server/lib/debugpatch-agent.jar -da -Dwls.home=/u01/oracle/wlserver/server -Dweblogic.home=/u01/oracle/wlserver/server weblogic.Server Picked up JAVA_TOOL_OPTIONS: "-agentlib:jdwp=transport=dt_socket,address=localhost:4002,server=y,suspend=n" ERROR: transport error 202: bind failed: Address already in use ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750] Stopping Derby server... Derby server stopped.

I then tried to work with docker-compose, creating a .yaml file to add my environmental props there, trying to prevent these from running twice. I got the exact same behavior. Whichever port I use, it is found Already in use.

This is my .yaml file

version: '2'
services:
  weblogic:
    container_name: weblogic_yamled
    image: store/oracle/weblogic:12.2.1.3-dev-200109
    ports:
        - "7001:7001"
        - "7002:7002"
        - "4002:4002"
        - "4003:4003"
        - "9002:9002" 
    volumes:
        - c:/my-path-to-shared-volume:/u01/oracle/properties
    environment:
        - ADMINISTRATION_PORT_ENABLED=true
        - DOMAIN_NAME=docker_domain
        - JAVA_TOOL_OPTIONS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=localhost:4002"

Finally, I tried transport=dt_shmem but then I got a different error:

ERROR: transport library not found: dt_shmem

Do not know what else I should try!

Answer 1

Try adding address=*:4002 instead of address=4002

Answer 2

JAVA_OPTS is a Tomcat specific environment variable

In Java 8 the JDK supports a JAVA_TOOL_OPTIONS environment variable so to enable the debugger. Try replace JAVA_OPTS with JAVA_TOOL_OPTIONS

You also have to setup the address like this: address=*:8000, address=localhost:4002 or address=0.0.0.0:4002

Answer 3

I had a similar issue with attaching a memory monitoring tool (JVisualVM). I could telnet to the server but that was not the whole story.

From what I have understood what was blocking me was the RMI connection used under the hoods. What was missing was a "tunnel" between client (where your debugger runs) and host (where your application runs) machine.

In windows you would open a cmd and give:

putty.exe -ssh <username>@<remote-host> -L <port>:<remote-host>:<same_port_again>

This will open a putty window which should remain open after logging in for the tunnel to remain open.

For more information on this, you can check here on the 2nd step of the solution provided by @freedev.

I am not sure if it works for you but I suspect it may be the same case as mine.