How to debug Java code in a local Maximo Manage development environment

In this short post, I would like to share the steps for debugging Java code in a local Maximo Manage development environment.

When you use the Maximo Application Suite (MAS) with OpenShift on your laptop, the CPU and memory occupancy is considerable and constant. If you also have to develop code, the resources become too scarce because the development environment & c. also requires a lot of them. Fortunately, recent versions of MAS offer a solution that makes it possible to create a local development environment based on a single container, therefore with significantly reduced memory consumption.

This approach works excellently, and Java programmers will find themselves wondering how to debug their Maximo code running in the container. The first thing to consider is that Maximo Manage no longer uses the historical WebSphere Application Server (WAS), but is based on WebSphere Liberty (WLP), IBM's next-generation application runtime designed for cloud-native applications.

To launch an instance of Liberty, simply run the 'server' command with the 'run' option to start it in foreground and the 'debug' option to start it in debug mode. Inspection of the Manage container reveals that a script is launched that runs the 'server' command with the 'run' options and the name of the instance on which the Manage is running:

The Docker/Podman 'run' command creates a new continainer with the ability to modify the arguments passed to the entrypoint. In our case, changing the option setting to 'debug'. It is also essential to expose the server's port 7777 to allow remote debugging:

docker run --name managedev-debug -p 9080:9080 -p 7777:7777 managedev:latest "/opt/ibm/wlp/bin/server" "debug" "defaultServer"        

Unfortunately, at this point things got complicated because the Eclipse debugger and even the Java JDB didn't want to know about connecting, obviously giving incomprehensible errors. After several attempts, investigations and fruitless google searches I finally understood the problem. The MAS WLP uses Java 11 and no longer Java 8 (yay! we are at least in 2018 ????):

sh-4.4$ /opt/java/openjdk/jre/bin/java -version
openjdk version "11.0.20" 2023-07-18
IBM Semeru Runtime Open Edition 11.0.20.0 (build 11.0.20+8)
Eclipse OpenJ9 VM 11.0.20.0 (build openj9-0.40.0, JRE 11 Linux amd64-64-Bit Compressed References 20230810_825 (JIT enabled, AOT enabled)
OpenJ9   - d12d10c9e
OMR      - e80bff83b
JCL      - f53b132192 based on jdk-11.0.20+8)        

From Java 11 onwards, remote debugging is not allowed by default and must be activated using specific agent settings. But in this context, the approach that seemed most appropriate and simple to me is the use of the environment variable WLP_DEBUG_REMOTE. I then recreated the container by enabling remote debugging by setting this environment variable to 'yes' and disabling the debugger's wait at start-up with the other environment variable WLP_DEBUG_SUSPEND (personal preference):

docker run --name managedev-debug -p 9080:9080 -p 7777:7777 -e WLP_DEBUG_REMOTE=y -e WLP_DEBUG_SUSPEND=n  managedev:latest  "/opt/ibm/wlp/bin/server" "debug" "defaultServer"        

The Eclipse debugger then immediately connected and as a test I tried to successfully set a breakpoint to the new Workqueue MBO:

That is all. Good debugging to all.