Re: Using RSE to debug running Java program - fails for me, what to do?

Xuan Chen skrev den 19-02-2008 18:09:

We don't recommand using Debug Job option to debug remote Java application. Actually, it is not officially supported by WDSC Integrated Debugger.

Thank you for your answer. I tried to locate this in the help text, and it appears to be that OPM and ILE is supported (with appropriate magic used). Bother.

For attaching to remote java application, you could use the Eclipse basic support for debugging remote java. Steps:

. Create a Java project in your workspace, with the java source your want to debug
. add the following options when the JVM is started:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
. Create a new Remote Java Applicaiton launch configuration, specifying the java project, Connection Properties (host name, and the port #, which is 8000 in this case), and debug the application.

I am aware of this possibility, and it is this approach I am looking for alternatives to for _production_ situations. I do not like having to explain to the customer that we need a unique global port assigned to each and every Java program running on this machine (our product supports numerous installations on the same iSeries) and that each of these open ports basically allow anyone with a Java debugger to hot deploy and hence run arbitrary code on the machine.

However, we still need to diagnose and fix production issues where it is very interesting to be able to peek inside the program while it is running in the problematic situation. Here the "attach the standard iSeries debugger" is very, very relevant, and if there is _any_ way to get any version of the iSeries debugger to do this it will be a MAJOR benefit over any Sun based JVM (to my knowledge). I have managed to attach the "iSeries™ System Debugger" (the one in tes.jar) to a Java job, but am still learning how to do this.

We currently deploy in jar-files without source (which it appears to be able to find on the client), but I am willing to change to a deployment model which would allow in-vivo peeking inside the JVM. Any help in getting there will be much appreciated.

Thanks again,