Welcome

Developing Java web application seems to be easy at first glance. You will achieve good results in case you respect some common best practice and basic design patterns. E.g. before you start designing a web application you should think besides business and non-functional requirements about

• hiring a team of well-skilled, experienced developers
• choosing a good framework based on the dependency injection paradigm
• junit tests covering all parts of the software to develop
• convincing the business people that web-based application have limitations and may not provide the full feature set of a rich client application (that is not longer true in the field of Ajax where an additional layer is put on the top of the HTML/HTTP technology stack. If you plan to use Ajax consider to step further and use a framework like RAP which provides a swing like programming model).
• designing a stateless application, following the original hypertext idea of HTML and HTTP

But sometimes your influence on the issues mentioned above is rather limited: You join the project team in a late project phase, the development has already started. The managers have decided to choose one of their favorite legacy frameworks because some so-called experts have spread their ideas in a computer magazine telling them that using the appropriate framework is a good idea to build the world on top of it. In addition the business people may have already specified a rich client GUI. Furthermore the project managers are not aware of the complexity of the GUI and assign development tasks for the user interface to novice developers, and those developer guys tend to put whatever they want in the session context and in the servlet context without thinking of browser navigation issues, concurrent requests in one browser session, object lifecycles and a clean up mechanism.

Finally this will all end in a disaster due to not reproducible errors because of the huge amount of navigation paths through the application. In addition, thousands of objects are hanging around in all the contexts of the servlet API. In the end, developing and debugging servlets within this project is no fun at all.

Servletspy is not able to save the world and bring back the paradise to you, but it may help to analyze an error-prone web application. Servletspy gives testers and developers a helping hand to identify problems of a buggy servlet application.

Servletspy introspects the content of the request context, the content of the session context and the content of the servlet context and appends a HTML representation of the retrieved data to generated HTML pages for every incoming HTTP request. The strategies used for introspection and visualization purpose are pluggable. The standard HTML visualization strategy is treelike. So the developers may dive into the structure of the objects available in the contexts to identify a problem. Generally, a tester is not interested in information representing the internal state of an application, so a tester does not run the application to test in JVM debug mode. By using Servletspy a tester may pass the information appended by the Servletspy to the issue tracking system to provide hints to developers helping them to track down the source of an error.

The sample page provides a simple example demonstrating what kind of output a developer or tester may expect from Servletspy. You may click on the tree elements to expand or collapse subtrees.