Tomcat

Remote Debugging

How do I configure Tomcat to support remote debugging?

The short answer is to add the following options when the JVM is started:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

There are a number of ways you can do this depending on how you normally start Tomcat:

• If you are using shell scripts to start Tomcat, start it with the following command:

  catalina jpda start
  

  It will start Tomcat so that a remote debugger can be connected to port 8000.

  The above mentioned options can be provided by setting certain environment variables. See the comments at the top of catalina.sh or .bat file for details.

  For example, the port number and JPDA transport implementation can be set with JPDA_ADDRESS=8000 and JPDA_TRANSPORT=dt_socket.

• If you run Tomcat using service wrapper, add the above JVM options before any other JVM options. Check the documentation for the service wrapper to determine how to set JVM options.
• If you start Tomcat from within an IDE, check the documentation for the IDE to determine how to set the required JVM options.

The port does not need to be set to 8000, it may be any value appropriate for your system.

Whilst this is very useful in development it should not be used in production because of both security and performance implications.

How do I remotely debug Tomcat using Eclipse?

This answer assumes that you have a project set up and have some idea of what you are doing in this respect. If not then that is really outside the scope of this topic and you need to go to eclipse.org and read up on how to use your IDE, and maybe practice a little bit before you come back to this. We are also going to assume that you have some idea of what a debugger is and how to use one.

• Make sure that Tomcat is started in remote debugging mode as described above and that your app is deployed.
• Make sure that you have the sources for the code that you are trying to debug in your IDE. For the libraries and for Tomcat itself you can "attach" the sources to the jar files: open a class file and then click "Attach Source..." button.
• If you have a servlet or something, set a breakpoint where it is sure to hit on the next request.
• Go to "Run->Debug Configurations...". Click on "Remote Java Applications", then click "New". Type in the title. Note that port 8000 from the Tomcat instructions. Save and run.
• Eclipse will connect to the JVM that Tomcat is running under. Wow, that was easy!

Now go type the url to submit to your servlet or whatever in your browser. Boom you hit the breakpoint right? Have fun!

How do I remotely debug Tomcat using NetBeans?

This answer assumes that you know how to work with a NetBeans Project, and also how to use the NetBeans debugger. If not, please go to http://www.netbeans.org/kb/using-netbeans/40/debug.html and read up on how to use NetBeans and its debugger.

Starting with Tomcat trunk revision 1484409, the Tomcat source includes Ant tasks to configure your source directory as a NetBeans Free-Form Project. After you have successfully run Ant with the default build target (deploy), you can then run the ide-netbeans target. This task will configure your sandbox copy of Tomcat so the source can be inspected, maintained and debugged under the NetBeans IDE. You should follow the detailed instructions in the README.txt file that will have been installed in your new nbproject directory.

Make sure that Tomcat is started in debug mode as described above, that your application is deployed, and that the sources are all defined as resources in your application. If you have a servlet or JSP file, set a breakpoint where you think a problem might be occurring. Go to "Run->Attach Debugger". A dialog pops up to let you specify the following options:

• Debugger: JPDA Debugger
• Connector: SocketAttach
• Host: The IP address of the host your Tomcat installation is running on (127.0.0.1 if it is your local machine).
• Port: The port of your Tomcat debugging interface, which should be 8000 if you've followed the instructions above.

When you press OK, you have a debugging connection very similar to local debugging.

Note that NetBeans has a second option -- you can debug JSP files and servlets locally using a Tomcat server that is bundled with the IDE. When you debug a JSP file or servlet in the IDE, the bundled Tomcat server automatically starts in debug mode, and the debugger connects to it.

The Tomcat NetBeans targets have not yet been back-ported to Tomcat 7. You can copy the files from your copy of the trunk and they should only require minimal editing of paths to work with older versions of Tomcat.

JMX Monitoring via Java VisualVM

Zum (Remote) JMX Monitoring eines Tomcat müssen die folgenden JVM Parameter spezifiziert werden.

Dcom.sun.management.jmxremote.port=8090
Dcom.sun.management.jmxremote.ssl=false
Dcom.sun.management.jmxremote.authenticate=false

Namensgebung der WAR Datei

Bei der Namensgebung einer WAR Datei ist zu beachten, dass der Dateiname einen direkten Zusammenhang mit dem Context Name, dem Context Path und der Context Version besitzt. Hierzu kann auch die Tomcat Hilfe zum Thema Context eingesehen werden: siehe hier.

Im folgenden ist ein Auszug dieser Hilfe.

Naming

When autoDeploy or deployOnStartup is used then there is a close relationship between the context name, context path, context version and the base file name used for the WAR and/or directory that contains the web application when the WAR or directory is located in the Host's appBase. When no version is specified, the rules are:

• contextName = contextPath
• If the contextPath is a zero length string, the base name is ROOT
• If the contextPath is not a zero length string, the base name is the contextPath with the leading '/' removed and any remaining '/' characters in the path replaced with '#'.

When a version is specified, ##version is added to the contextName and base name. To help clarify these rules, some examples are given in the following table.

Context Path	Context Version	Context Name	Base filename
/foo	None	/foo	foo

/foo/bar None /foo/bar foo#bar Empty String None Empty String ROOT /foo 42 /foo##42 foo##42 /foo/bar 42 /foo/bar##42 foo#bar##42 Empty String 42

1. 1. 42

ROOT##42 The version component is treated as a String both for performance reasons and to allow flexibility in versioning schemes. String comparisons are used to determine version order. If version is not specified, it is treated as the empty string. Therefore, foo.war will be treated as an earlier version than foo##11.war and foo##11.war will be treated as an earlier version than foo##2.war. If using a purely numerical versioning scheme it is recommended that zero padding is used so that foo##002.war is treated as an earlier version than foo##011.war. If you want to deploy a WAR file or a directory using a context path that is not related to the base file name then one of the following options must be used to prevent double-deployment: Disable autoDeploy and deployOnStartup and define all Contexts in server.xml Locate the WAR and/or directory outside of the Host's appBase and use a context.xml file with a docBase attribute to define it.