ObjectSnoop |
|||||||||||||
Inspecting objects in Java
|
|||||||||||||
ObjectSnoop Homepage Features History Download Contact Links Manual SourceForge Project homepage Website | As well as being used in ordinary Java programs, ObjectSnoop can also be incorporated into Servlets and Java Server Pages (JSP's). Additional support is provided for JSP's in the form of a tag library. This largely replaces the need for the use of scriplets to embed java code within a JSP page. The HTML formatter is a natural choice for this area of Java technology, and the HTML output produced by ObjectSnoop is well formed. You can display the output in a JSP page or Servlet response in any place that you might put an HTML table. This chapter assumes that you're already familiar the API of Servlets and JSP's. In addition you should also know how to use ObjectSnoop in ordinary Java classes, and understand how filters and the supplied factory classes work (Chapter 3). It's likely you'll have to follow some of the special installation requirements (Section 2.2) for getting ObjectSnoop to work with your servlet container. As servlets are a class that implements a particular interface, the use of the ObjectSnoop director is the same as in any other Java class (Chapter 3). If you want the output to appear in the web page served to the client, then you need to use the writer associated with the HttpServletResponse object. Drawing on the use of the SnoopFactory and some of the custom filters, this example snoops both the implementation and the filtered information about the HttpServletRequest.
For simplicity, the exceptions thrown by the doGet() method aren't shown. There are three important issues arising when using ObjectSnoop in a servlet. The first concerns threading, the second applies to any reuse of a SnoopDirector, and the last involves interaction with JSP page buffering. The environment in which servlets are used is multi-threaded. Unless steps are taken to protect the code, there is the possibility that the same servlet will be executing on two different threads at the same time. The SnoopDirector isn't thread aware, so any synchronization needs to be performed externally. If you're planning on keeping the SnoopDirector around in, for example, an instance variable, you need to protect it in a synchronized block like this:
Re-using a SnoopDirector may cause problems because of some subtle interaction with your servlet container, or even because of the servlet specification itself. The JspWriter won't be the same for each servlet response, and a formatter is usually tied to a single Writer. In this situation a director stored in a class instance variable (or somewhere comparable like the session or application context) would lead to unexpected behaviour when that JspWriter expired (usually because the response has been served). More subtle interraction is possible when there is nested JspWriter behaviour. This is occurs within buffered tag libraries (and possibly elsewhere in the JSP specification), and may result in output appearing in unexpected places on the served page. ObjectSnoop can produce a large quantity of output that overflows the response output buffer. Once this buffer has overflowed and part of the response page has been sent to the client, any mechanisms dealing with thrown exceptions, or page forwarding through a RequestDispatcher, may no longer work as expected. You can use JSP scriptlets to setup and snoop objects, acting as an alternative to using the tag library that supports ObjectSnoop. Embedding Java code withing a JSP page achieves the same effect as programming within a servlet. Any variable available to you within the scope of the scriptlet can be snooped. If you're going to import the ObjectSnoop package then you'll need to write something like this:
Again you can shorten the code by using the fully qualified class path:
The tag library encapsulates things that are frequently snooped within a JSP. Probably the biggest reason for using them is the reduction in the amount of typing. For ObjectSnoop to be used as a tag library it needs to be installed in a place where the tag identifier can be located (Section 2.2). Then each JSP needs to have the tag library connected to that page through the use of the taglib directive. The URI of the ObjectSnoop tag library is /objectsnoop, and this example connects it to the snoop prefix:
The prefix that you use for the tag library controls how you identify the tags on that page that belong to ObjectSnoop. This allows you to control and prevent name collision. At the moment there are only a few tags, and they give access to frequently used parameters and objects used in the JSP environment. These tags are described using the snoop prefix given in the taglib example above. You're free to choose your own unique tag prefix. Examines the attributes, parameters, and information provided by public methods contained in the HttpServletResponse object associated with the JSP page.
Examines the attributes and information provided by public methods contained in the HttpServletResponse object associated with the JSP page.
Examines the session attributes and information provided by public methods of the HttpSession object associated with the client requesting the JSP page.
Examines the cookies attached to the HttpServletRequest object. Any cookies set in the page response are not shown.
Examines the object representing the JSP page context. It is likely that this information will contain implementation specific class structures, as well as any beans currently available within page scope.
Examines the named bean found in the specified scope. If the scope is not provided then they are searched in the order page, request, session (if valid), application.
| ||||||||||||