Debugging Techniques

---

A common debugging technique is the strategic insertion of System.out.println() statements at key points in code. It's certainly mine. The problem is that it's an invasive technique; it requires the modification of the source code. Modifying the source code might be acceptable at development time, but what if we want to investigate the inner workings of an deployed application, or one for which the source code is not available?

What we need is a non-invasive mechanism that can be easily added and removed with no adverse effects on the classes being scrutinized. All of the techniques described in this chapter are non-invasive:

• Filters can trap servlet invocations as they occur, which allows us to record the sequence in which requests are processed

• Event listeners provide an insight into how the container handles sessions and context variables

• The Java Platform Debugger Architecture (JPDA) provides the basis for a comprehensive debugging tool that rivals those that are commercially available

Debugging Tools

An Integrated Development Environment (IDE) such as VisualAge or JBuilder will incorporate a debugger and these days there's a good chance it will also offer distributed debugging facilities for web applications. There are some good third-party debugging and profiling tools too. However, there are downsides to using some of the commercial debugging tools:

• They may be proprietary, which means that we can only debug servlets that are running in the servlet engine of the IDE itself, or in the vendor's application server

• They can be difficult to configure

• They can be expensive

• The information provided by those tools, though comprehensive, might not be quite what we require

In this chapter we'll focus on how to apply some simple techniques that are platform- and vendor-independent. These techniques will allow us to just capture the information we need (and for free).

I'm not against using tools, and I understand the "buy, don't build" philosophy. But you'll be able to make a more informed decision about what tools will suit you once you know what the do-it-yourself approach has to offer.

There is a non-proprietary, free, debugging tool called JDB. Although now superseded by JPDA, there is still a JDB tool provided as an example JPDA client with the JDK. You'll learn a lot by taking a look at the source code for the new JDB in file %JAVA_HOME%\demo\jpda\examples.jar (the class to examine is com/sun/tools/example/debug/tty/TTY.java).

Event-Driven Debugging

Automated debugging is an event-driven process. When certain events occur in the target program, the debugger application must be alerted to that event so that it may take appropriate action. The kinds of events we'll be interested in are:

• Method calls, particularly those that result in servlet invocations

• Updates to values stored in variables, particularly session and context attributes

• The creation and destruction of objects, particularly session and context instances

The appropriate action by the debugging application may be passive (simply reporting what happened) or active (perhaps halting the program and affecting its future course).

Filters and event listeners are by their very nature passive. The JPDA approach we will take will also be passive but it's worth pointing out that with JPDA it is possible to take a more active role by taking control of the target virtual machine. It's not a good idea to halt or take control of the servlet container, as it may be running other web applications.

---