Tags

redhat
employment
ripple
interfaces
ncurses
ruby
refs
filesystems
retro gaming
raspberry pi
sinatra
3d printing
nethack
gcc
compiler
fedora
virtfs
project
gaming
vim
grep
sed
aikido
philosophy
splix
android
lvm
storage
bitcoin
projects
sig315
miq
db
polisher
meditation
hopex
conferences
omega
simulator
bundler_ext
rubygems
book review
google code in
isitfedoraruby
svn
gsoc
design patters
jsonrpc
rjr
aeolus
ohiolinuxfest
rome
europe
travel
brno
gtk
python
puppet
conference
fudcon
snap
html5
tips
ssh
linux
hardware
libvirt
virtualization
engineering expo
cloud
rpm
yum
rake
redmine
plugins
screencasting
jruby
fosscon
pidgin
gnome-shell
distros
notacon
presentation
rails
deltacloud
apache
qmf
passenger
syrlug
hackerspace
music
massive attack
crypto
backups
vnc
xsd
rxsd
x3d
mercurial
ovirt
qpid
webdev
haikus
poetry
legaleese
jquery
selenium
testing
xpath
git
sshfs
svg
ldap
autotools
pygtk
xmlrpc
slackware

Nov 29 2007

Debugging Tomcat Using JDB

As a fan of Vim and console development and a staunchent opponent of IDEs (not that they don’t have their merrits, they are simply too complicated and too prone to breaking when some miniscule setting is changed IMO), I attempted to figure out how to debug Tomcat using the command line java debugger yesterday. To do so, you will need todo a few things; mainly enable debugging support in the server, locate the source code corresponding to the servlet you will be debugging, and familiarize yourself with the JDB tool.

By default if you run the tomcat startup script catalina.sh with parameters “jpda start” the server will automatically be placed in debugging mode. There are a few caveats to this, and you can configure the behavior of this by opening up catalina.sh and looking at the config options described at the beginning of the file. Whatever you decide to change will need to exported before the script is run, so for example to change the default behavior to force the server to wait until a debugger is attached and the “run” command is invoked (before it tries to load any servled) you would issue a

   "JPDA_SUSPEND='y'"

You may desire to change some of the other default values, for example the default debugging port Tomcat uses (8000) as it may be employed by some other service (in Fedora 7, the network audio server (nas) is enabled by default and uses that port)

Next you will need to have access to the source code backing the servlet you are debugging. Unfortunately jdb cannot read source out of a jar so you will need to uncompress any source directories that you may have and specify their location to jdb via the command line (though now irrelevant, I discovered yesterday maven can create a source-jar with the “maven-source-plugin” plugin). To start debugging, simply issue the following command:

  "jdb -attach 8000 -sourcepath dir1:dir2:dir3"

(obviously changing the port and colon seperated source directory list). If the sourcepath isn’t specified, the default will be ‘.’. Furthermore, since java uses the full package/class name to refer to classes, which ties into the paths which they are located, you will need the entire correct directory structure setup correctly under the sourcedir(s) (eg. if you want to debug com.foobar.Class you will need com/foobar/Class.java under one of the sourcedirs specified

You should now be in debugging mode (recall that if the Tomcat suspend option is set, you will have to issue ‘run’ before the server execution continues). Though I do not have the space to detail everything here, I will list some of the more useful commands that I’ve found:

If everything went as expected you should now be able to debug any servlet running in Tomcat. Pretty simple huh? While JDB isn’t the most user friendly debugger, it is very simple and intuitive, a value which I hold dearly.