| < Free Open Study > |
|
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.
| < Free Open Study > |
|