Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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

New features added to Servlet 2.5

Servlets updated with annotations, web.xml conveniences, and more

By Jason Hunter, JavaWorld.com, 01/02/06

Page 4 of 5

Regarding session tracking, Servlet 2.5 eased a rule dictating that a servlet called by RequestDispatcher include() couldn't set response headers. This rule's purpose was to keep included servlets constrained within their own space on the page, unable to affect the page outside that area. The rule has eased now to allow request.getSession() calls within the included servlet, which might implicitly create a session-tracking cookie header. Logic dictates an included resource should be constrained, but logic also dictates those constraints shouldn't eliminate the ability to initiate a session. This change proves especially important for the Portlet Specification. Note that if the response was already committed, the getSession() call will throw an IllegalStateException. Previously, it would have been a no-op.

Clarifications

Lastly, the new specification clarifies several edge cases to make servlets more portable and guaranteed to work as desired.

Response closure

The first clarification is trivial and esoteric, but interesting as an example of the unintended side effects you sometimes see in a specification. The Servlet 2.4 specification dictates that the response should be committed (that is, have the response started with the status code and headers sent to the client) in several situations including when "The amount of content specified in the setContentLength method of the response and has been written to the response." This appears all well and good until you write code like this to do a redirect:

 response.setHeader("Host", "localhost");
 response.setHeader("Pragma", "no-cache");
 response.setHeader("Content-Length", "0");
 response.setHeader("Location", "http://www.apache.org"); 

The servlet technically must ignore the Location header because the response must be committed immediately as the zero byte content length is satisfied. The response is over before it began! Servlet containers often refuse to implement this behavior, and the Servlet 2.5 release adds "has been greater than zero" to the rule.

Encoding edge cases

The Servlet 2.4 specification says you must call request.setCharacterEncoding() before calling request.getReader(). However, it does not say what happens if you ignore this advice and make the setter call after the retrieval. For portability, it's now clarified to be a no-op.

Cross-context sessions

Lastly, the rules around cross-context session management have been clarified. This comes into play when servlets dispatch requests from one context to another. Within the target call, what session should be in scope, if any? The issue came up most prominently with portlets, where a main page in one context may do several include calls to portlets in another context. Servlet 2.5 now specifies that resources within a context see the session for that context, regardless of where the request may have started. This means the portlets can track their own state separate from the main page state, and this rule will apply across servlet containers.