Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Servlet 2.4: What's in store

A full update on the latest servlet spec

By Jason Hunter, JavaWorld.com, 03/28/03

  • Print
  • Feedback
.

Page 3 of 5

  • javax.servlet.include.request_uri
  • javax.servlet.include.context_path
  • javax.servlet.include.servlet_path
  • javax.servlet.include.path_info
  • javax.servlet.include.query_string


However, these work just the opposite of the forward() attributes. In an include(), the path elements don't change, so the include attributes act as the backdoor to access the target servlet's path elements. Compare this with a forward() where the path elements change so the forward attributes represent the backdoor to the original path elements. Yes, it gets complicated. As soon as servlets began to use the URI space as an internal dispatch mechanism, the door to complexity opened.

Another area where we see this complexity is in the interaction between the RequestDispatcher and filters. Should filters invoke for forwarded requests? Included requests? What about for URIs invoked via the <error-page> mechanism? Before Servlet 2.4, these questions were left as open issues. Now Servlet 2.4 makes it a developer's choice. There's a new <dispatcher> element in the deployment descriptor with possible values REQUEST, FORWARD, INCLUDE, and ERROR. You can add any number of <dispatcher> entries to a <filter-mapping> like this: 

<filter-mapping>
  <filter-name>Logging Filter</filter-name>
  <url-pattern>/products/*</url-pattern>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>FORWARD</dispatcher>
</filter-mapping>


This indicates the filter should be applied to requests directly from the client as well as forward requests. Adding the INCLUDE and ERROR values also indicates that the filter should additionally be applied for include requests and <error-page> requests. Mix and match for what you want. If you don't specify any <dispatcher> elements, the default is REQUEST.

The last RequestDispatcher change is to allow, for the first time, relative paths in request.getRequestDispatcher() calls. The path will be interpreted relative to the current request's path. It's a minor change, but comes in handy when dispatching to a sibling servlet.

Listeners

Servlet 2.3 introduced the idea of context and session listeners, classes that could observe when a context or session was initialized or about to be destroyed, and when attributes were added or removed to the context or session. Servlet 2.4 expands the model to add request listeners, allowing developers (or more likely tool vendors) to observe as requests are created and destroyed, and as attributes are added and removed from a request. Servlet 2.4 adds the following classes:

  • ServletRequestListener
  • ServletRequestEvent
  • ServletRequestAttributeListener
  • ServletRequestAttributeEvent


These classes have been modeled after the familiar ServletContextListener, ServletContextEvent, ServletContextAttributeListener, and ServletContextAttributeEvent design, and are assigned to execute using the same <listener> elements. The request variety of listeners were added primarily to help debugging tools hook into the request handling. The practical applications beyond that may be slim, so I don't dig into details here.

  • Print
  • Feedback

Resources