Choosing a Debugging Technique

---

The three techniques we've looked at are not mutually exclusive. It's perfectly possible to combine output from all three methods in a single output file or, with a bit of ingenuity, pass it through to a real-time debugger front-end of a centralized logging service (perhaps an Enterprise JavaBean). Combining all three will give the most comprehensive picture of what's going on inside your servlets and the container.

The filter and the event listener are particularly cohesive because they are so similar in operation and in deployment. So we'll put them together and contrast that combination with the JPDA approach.

You might think that the JPDA is the obvious choice because:

• We can watch any combination of classes that comprise your web application, plus those of the supporting container

• We can run the debugger front-end on a remote machine

• It's not limited to servlet debugging

However, the runtime overhead and the relative complexity of the API mean that:

• The servlet container runs much slower in debug mode, so it's not ideal for tracking problems in a live system, particularly performance problems

• A JPDA debugger front-end is much more difficult to write than a filter and event listener combination

• The sheer level of information produced as output can make it difficult to pick out the important details

Also, if you work in a corporate environment that restricts your control over the server, you'll have to convince someone else to start it up in debug mode.

The main limitations of a filter and event listener combination are:

• The range of events that you can trap is quite limited

• It is limited to debugging servlet applications

• We have to modify the deployment descriptor for each application that we wish to debug, although (crucially) not the code of the servlets themselves

Of course, the limited information available via this approach may be exactly the kind of information you want for servlet debugging. You might simply want to know:

• Which servlets are invoked, in what order, from which remote clients, and with what request parameters

• When sessions and contexts are created and destroyed, and how the attributes are managed so as to maintain isolation between multiple client requests

Also, there is very little impact on performance, which makes this approach suitable for performance measurement.

The information provided by the filter and listener combination is much more meaningful in a web context. Messages are sent from IP addresses to servlet URLs or to numbered sessions, and the messages provide the parameter and attribute values, not just the method signatures. Getting that kind of meaningful information out of the JPDA would not be so easy.

Filters and event listeners are my preferred approach for debugging web applications. They're easy to write, easy to deploy, have a low performance overhead, and provide meaningful (if somewhat limited) information. A well-written filter or listener class is a handy component that can be inserted into any web application.

---