William WITTWER has been a consultant with Borland since 2001; he joins the team dedicated to IDEs to focus on JBuilder, Borland Developer Studio, as well as the Interbase and JDataStore databases. On top of his consulting activities with major clients (Crédit du Nord, quite a few government agencies, HP, Thales, France Telecom), William heads sessions at Borland conferences, writes technical articles, and answers technical questions on these solutions. You may contact him via email at william.wittwer@borland.com
When testing recent developments, we often need to launch debugging sessions in order to see what is really going on in local variables, method call chains, etc.
In traditional Client/Server development, one can simply launch their application in a classic debugging session; in distributed development, however, applications can be spread amongst many servers, whether on a partitioned machine or on many systems; the problem lies in performing debugging sessions without necessarily being on the same machine as that which we want to debug.
The JPDA (Java Platform Debugger Architecture) provides development tools with the necessary infrastructure to debug in those circumstances. The JBuilder debugging functionalities make use of this architecture.
In this white paper, we will show the simple steps needed to configure a remote virtual machine and our JBuilder to easily debug such applications.
Configuring the launch of the remote virtual machine to debug
Options need to be added to the standard launch of a virtual machine (VM) to enable the debugging architecture, allowing us to attach (hook in) and collect data.
-Xdebug |
Enables remote debugging. |
-Xnoagent |
On a Sun VM, disables the proprietary debugging interface thus letting JPDA work correctly. |
-Djava.compiler=NONE |
Disables Just-In-Time (JIT) compilation. |
-Xrunjdwp: transport=dt_socket, server=y, address=5000, suspend=y |
Loads JDWP (Java Debug Wire Protocol), the reference implementation of JPDA. Sub-options further specify the option. |
transport=dt_socket |
Sets the transport type for the connection with the debugging application; in this example, we will connect via a socket. |
server=y |
Tells the VM whether it must be receptive to an attaching debugging application. |
address=5000 |
The port address for our connection; we will need 5000 for our example. |
suspend=y |
This option can be set depending on whether we want to suspend the exectution of the VM until a debugging application connects. This is useful if we seek to understand what happens when a server starts. |
|
|
If we wish to make the VM wait for a connection before a full launch, we will need a command line such as this :
java …. -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,address=5000,suspend=y
If we want the VM to be fully executing and listening for a debugging application, we will require a command line such as this one :
java …. -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,address=5000,suspend=n
Figure 1 : JBoss Example
Then, we can execute the connection chain from JBuilder to collect data, use breakpoints, etc.
Figure 2 : Server launch
Attaching into a remote virtual machine
To hook into the VM that we just launched, we will create a new execution configuration within JBuilder.
Click on Run/Configurations…
Then click on New to create the desired configuration..
Figure 3 : New configuration creation wizard
Give it a name, then specify that the run will be of type Server. Then, choose the Connection item under Debug in the left-hand tree.
Figure 4 : Port specification
We specify that we will attach remotely and set the port to that which we chose previously (5000 in our example)
We then run the configuration and attach to the server by clicking the debugging button and choosing the configuration we just created (See figure 5).
Figure 5 : Running the configuration and attaching
As we chose the suspend=y command-line sub-option, the JBuilder debugger is immediately put on pause, allowing us to to execute the server step-by-step and verify the contents of variables at startup.
Figure 6 : Hooking completed, debugger paused
Using the debugger
Now, we can add breakpoints on our server-side code in JBuilder by clicking on the line number and hitting the F5 key.
Figure 7 : Adding a breakpoint
If we run the application using the code line where a breakpoint has been set the debugger will stop automatically, allowing us to investigate.
Figure 8 : The program stops on the breakpoint
This way, we can run the server-side code step by step and see what is really happening on the server while we call these components.
Figure 9 : Variable investigation / Step-by-step execution
Conclusion
As we saw in this white paper, using remote debugging is easy when we know the right parameters to specify and the steps necessary to set it all up. JBuilder 2006 features a number of debugging options and brings productivity gains thanks to its rich set of functionalities, such as the EJB, Web Services and GUI wizards, the tools to generate code very quickly, and the support for numerous application servers and databases on the market. It also allows JDK 5.0 development. JBuilder’s advanced peer-to-peer collaboration tools let developers work seamlessly together, whether they are on the same PC or on opposite sides of the planet (collaborative editing and debugging, active differentiation, etc.)
I invite you to download the latest version of JBuilder from this link if you don’t already own it : http://www.borland.com/downloads/download_jbuilder.html
William WITTWER (william.wittwer@borland.com)
Translated from French by Louis-Eric Simard (bdn@louis-eric.com)
