Software development techniques behind the magic user interface

Multi-Touch Developer Journal

Subscribe to Multi-Touch Developer Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Multi-Touch Developer Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Multi-Touch Authors: Will Davis, Ben Bradley, Qamar Qrsh, Suresh Sambandam, Jayaram Krishnaswamy

Related Topics: JBoss Enterprise Middleware, Eclipse Platform

JBoss: Article

Eclipse Special: Remote Debugging Tomcat & JBoss Apps with Eclipse

So without further ado here is how I use Tomcat, JBoss, and Eclipse to build and debug applications

To view our full selection of recent Eclipse stories click here

Over the last several weeks I've received a few questions about remote debugging with Eclipse. I posted about this on my other blog back in February here but with not enough info for others to follow.

If you go look at that blog entry you will see that I looked into 'in eclipse' debugging but did not find it satisfactory.

So without further ado here is how I use Tomcat, JBoss, and Eclipse to build and debug applications.

Whichever platform you are using (Tomcat or JBoss) you need to start them with the JPDA debugging enabled. For Tomcat this is very easy. In the $CATALINA_HOME/bin directory there is a script catalina.sh. If you provide the arguments 'jpda start' tomcat will startup and listen on port 8000 for a debugger connection.

With JBoss its only slightly more complicated. Basically you need to specify the JAVA_OPTS to have java start up listening for debugger connections. I typically copy the $JBOSS_HOME/bin/run.sh to $JBOSS_HOME/bin/run-debug.sh but you can just as easily setup the JAVA_OPTS environment variable and use the run.sh script.

The value of JAVA_OPTS needs have -Xdebug -Xrunjdwp:server=y, transport=dt_socket,address=4142, suspend=n specified.

So this is what is going on with this argument list

  • Xdebug == start the jvm and listen for debugging connections
  • Xrunjdwp... == the info on how to connect to do remote debugging
  • server=y == start in server mode (i.e. wait for connections, don't go out looking to connect
  • transport=dt_socked == use sockets, this works (I think) only on unix (I'm on a mac), on Windows you have to use shared memory via the transport=dt_shmem argument instead. I'm fairly sure this works but its been a while since I tried it on Windows. YMMV. Here is the official info on the connection arguments
  • address=4142 == the port to connect to or the shared mem address to use
  • suspend=n == don't wait for a debugger to tell you what to do, go ahead and launch

Once you have JBoss or Tomcat running and listening for debugging connections you are good to go for connecting with Eclipse

The first thing you need to do is create a 'debug launch configuration' by bringing up the launch configuration editor. Figure 1 shows the menu item to invoke to make that happen

When the launch config editor appears select 'Remote Java Application' from the 'Configurations:' selection list on the left hand side then click the 'New' button. Figure 2 shows the defaults that appear for me after hitting the 'New' button.

Since it defaults to the Tomcat port leave the port number set to 8000, if yours is different then change it to 8000. Notice also that you can specify the host to connect to. If you have access to the port and the process is running on another machine then you can debug the process remotely. This works out really well for those situations where it works fine in your local env but not in the test env. I usually rename the configuration (it defaults to the name of the project for me) to 'Debug Tomcat' or something like that.

The other options (Source & Common) can be ignored for now. If you have not already launched tomcat in debug mode do so now on the command line with $CATALINA_HOME/bin/catalina.sh jpda start. When its launched go back to the Eclipe launch configuration editor and hit the 'Debug' button. If you are not auto switched to the'Debug' perspective go there now. You should see a 'Debug View' that looks a lot like Figure 3.

Your code should be directly below the Debug View if you have the default layout still in place. If so go there and set a break point in one of your servlets' service methods (or any other code that is being executed in Tomcat, like a struts action or whatever) and then go to the Web browser and tickle the code that you have a break point set in. Notice that Eclipse suspends Tomcat at the breakpoint, comes to the front and lets you debug your program. Everything works just as if you were debugging locally.

Everything works the same within JBoss once you get it started with the debugging turned on. Keep in mind that you must set the port to match (in the above discussion of JAVA_OPTS it is set to 4142). So you need to create a new Debug launch configuration and specify 4142 as the port. Then you can debug your EJBs.

If you'd like to know more about this or you are having trouble making it work feel free to comment or send me an email.

Happy Debugging!

More Stories By Bill Dudney

Bill Dudney is Editor-in-Chief of Eclipse Developer's Journal and serves too as JDJ's Eclipse editor. He is a Practice Leader with Virtuas Solutions and has been doing Java development since late 1996 after he downloaded his first copy of the JDK. Prior to Virtuas, Bill worked for InLine Software on the UML bridge that tied UML Models in Rational Rose and later XMI to the InLine suite of tools. Prior to getting hooked on Java he built software on NeXTStep (precursor to Apple's OSX). He has roughly 15 years of distributed software development experience starting at NASA building software to manage the mass properties of the Space Shuttle.

Comments (32)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.