Recipe 13.4. Enabling Remote Debugging

Recipe 13.4. Enabling Remote Debugging Problem You want to debug your Struts application running on a remote server. Solution Configure the JVM running your application server to use the Java Platform Debugger Architecture (JPDA). You will need to add the following options to the java command that starts your application server. Recipe 13.4.2.1 JDK 1.3 -classic -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y Recipe 13.4.2.2 JDK 1.4 -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y You can use any IDE or tool that supports JPDA debugging such as Eclipse, IntelliJ IDEA, and JSWAT. Discussion The JPDA has made debugging Java applications much easier: You can use any debugging tool you want independently of the application being debugged. JPDA allows you to debug a Java application running in a separate JVM on a remote server on your network. Your local JVM, running the debugger, connects to the remote JVM across the network using the host name and a known port. In the Solution, the address specifies the port. This approach works well when the two computers are the samefor example, your desktop machine. JPDA permits you to have two JVMsone for your IDE or debugger and one for the application serverthat can work together. You no longer have to run the application server and your IDE all within the same process. If you're using Tomcat as your application server, debugging is easier. Tomcat's startup scripts include the JPDA options shown in the Solution. By default, Tomcat reserves port 8000 for the JPDA port. Figure 13-2 shows how to start Tomcat, on a Linux/Unix machine, using the catalina.sh shell script. Figure 13-2. Starting Tomcat in debug mode (Linux/Unix) For Win32 machines, the catalina.bat startup script configures JPDA to use shared memory instead of TCP/IP sockets for the transport mechanism. The use of shared memory is only supported by Win32, and most IDEs don't support connecting using this transport; you're better sticking with the socket approach. If you're using a Tomcat on a Win32 machine, you have two main options: You can use the Cygwin Unix emulator and execute the catalina.sh shell script, or you can modify the catalina.bat file to use sockets. Change the variables for the transport and address as follows: ... rem set JPDA_TRANSPORT=dt_shmem set JPDA_TRANSPORT=dt_socket ... rem set JPDA_ADDRESS=jdbconn set JPDA_ADDRESS=8000 ... Of course, you can change the JPDA_ADDRESS to any available port you like and execute the catalina.bat file to start Tomcat in debug mode. Figure 13-3 shows the results. Figure 13-3. Starting Tomcat in debug mode (Win32) Once the application server is started, you connect to the server's JVM using your debugger. You only need to specify the host name and port for the remote JVM. As an example, here's how you would configure Eclipse IDE for debugging. You start by selecting Run Debug . . . from the Eclipse menus. Figure 13-4 shows the window displayed for creating a new debug run configuration. Figure 13-4. Configuring Eclipse for debugging Clicking the Debug button will attach to the remote JVM. Figure 13-5 shows the Eclipse Debug perspective; here, the breakpoint has been set within the Struts RequestProcessor. Figure 13-5. Eclipse debug perspective The latest IDEs have made debugging easier. If you debug using System.out.println( ) calls, logging messages, and educated guessing, learn how to use a debugger. It will save you hours, you'll learn about your application's internals, and you'll probably have some fun in the process. And because you have free access to the Struts source code, you can step down into the Struts framework if needed. See Also JSWAT, a standalone, JPDA-compliant, open source debugger can be downloaded from http://www.bluemarsh.com/java/jswat/. To learn more about using JPDA, see http://java.sun.com/j2se/1.4.2/docs/guide/jpda/conninv.html.