Servlet 2.4: What's in store

A full update on the latest servlet spec

1 2 Page 2
Page 2 of 2

Servlet 2.4 also attempts to clarify what happens when a listener throws an exception. Because a listener always invokes outside the service() call stack, the exception can't propagate to the servlet for handling. This issue remains undecided in Proposed Final Draft 2, but odds are listener exceptions will be handled by the <error-page> directive if it exists, and if not, will result in a simple 500 error to the client.

Session changes

Perhaps the most popular new method added in Servlet 2.4 is this one: HttpSession.logout(). This method provides a mechanism to reliably log out a user that logged in using one of the standard <auth-method> mechanisms (BASIC, DIGEST, FORM, CLIENT-CERT). Unfortunately, this method may also be the one that must be dropped from 2.4 before the final release. Placing the logout() call on the session assumes that the session manages the login, when, for everything but FORM logins, it won't. In BASIC, DIGEST, and CLIENT-CERT authentication, the client holds the login credentials and presents them to the server during the request. You can call logout() and empty the session, but the client will still send valid credentials. The server has no way to reliably make the client stop sending them. This is one reason why so many Webpages use form-based logins; they allow logout by invalidating the session or removing a client cookie.

Another 2.4 session change allows zero or negative values in the <session-timeout> element to indicate sessions should never timeout. In general, such an extreme measure should be avoided, but in some cases, it might prove useful if you manually call invalidate() in some reliable fashion. Use with caution.

Lastly, Servlet 2.4 changes from may to must the requirement that a distributed session throw an IllegalArgumentException if an object placed in the session can't be serialized or otherwise sent across the wire. The added restriction should help portability by avoiding silent failures.

Miscellaneous clarifications

Probably my favorite clarification in Servlet 2.4 is this: welcome files can be servlets. This means that index.tea with a *.tea handler can be the default file just as well as index.html or index.jsp. Most servers supported this, but some didn't, and now happily with 2.4, all must support it.

Also clarified is that any library files exposed by the container apart from the WEB-INF structure (such as the JARs Tomcat loads from $CATALINA_HOME/shared/lib) must be loaded by the same classloader within any single JVM. This enhances inter-Web application communication by avoiding potential ClassCastException problems.


Only one class or method was deprecated in Servlet 2.4, and this class sorely deserved it. SingleThreadModel (STM), a bad idea from the beginning, has been deprecated as of 2.4. STM is dead! Long live multithreaded programming! Although STM looks good at first blush, the alternate life cycle imposed by STM actually provides no benefits regarding thread safety, just a false sense of security. The expert group unanimously decided to deprecate it. For details on why STM should be considered harmful, see Resources.


The last change I talk about isn't a code change, but rather a format change. The web.xml file, formerly defined using a document type definition (DTD) now has its definition specified with the W3C's (World Wide Web Consortium) XML Schema language. Version 2.4 servers must still accept the 2.2 and 2.3 deployment descriptor formats, but all new elements are solely specified in Schema.

Schema is a much more verbose language than DTDs, more expressive in some ways and less expressive in others. Some restrictions have been added, like <role-name> uniqueness. Others have been relaxed; for example, the ordering of elements directly under <web-app> is no longer fixed, and <distributable/> may appear any number of times without error. Also, the <description/> tag now supports an xml:lang attribute to indicate which language is used in the description if not English.

Simple servlet containers aren't required to validate against Schema; J2EE containers are. The spec warns developers, "The deployment descriptor must be valid against the Schema," and that's good advice for portability. For the most part, the change from DTDs to XML Schema won't affect the average servlet programmer; however, it does make understanding the new web.xml format more difficult if you don't have help.

One feature of Schema (or bug, depending on how you look at things) is that elements in the web.xml file can be defined in other Schema documents from other J2EE specifications. So while the Servlet 2.4 web.xml schema mentions <message-destination>, <message-destination-ref>, and <service-ref> and dictates where they may go in web.xml, these elements' actual definitions and children are imported. Also, some elements that formerly were defined within the Servlet specification have been removed and, while still referenced by name, now get their definitions from the J2EE specification. This list includes <env-entry>, <ejb-ref>, <ejb-local-ref>, <resource-ref>, <resource-env-ref>, and all their many possible child elements. You'll also see that the <jsp-config> element definition has been moved into the JSP (JavaServer Pages) specification, although it too still appears in the Servlet schema by name.

How all these imports are supposed to be managed hasn't been made clear. And

it definitely seems odd for a technology low in the stack like servlets to

reference a technology above it, such as how <service-ref>

gets imported from JAX-RPC. It's like TCP/IP needing to know about HTTP. Sun

has said before that standalone servlets aren't a high priority, which

probably helps explain some of this integrated design. How this tight

coupling plays out as the specs continue to update will be interesting to


What you don't see

Version 2.4 drops a few interesting things. One is Schema extensibility, present until the Public Final Draft stage but removed in Public Final Draft 2. The extensibility proposal intended to provide a way to add even more third-party elements to web.xml files. It was removed at the expert group's behest because using a single file for configuration quickly creates an unworkable mess, like putting all your source code in the same file.

A few other items were postponed. One is the New I/O (input/output) API, an exciting new J2SE feature that greatly speeds client-server communication thanks to a new channel metaphor that lets you buffer in system memory and memory-map files, leverage DMA (direct memory access), and scatter/gather hardware devices' I/O features. Unfortunately, for Servlet 2.4 to use New I/O and channels, J2SE 1.4 would have been set as a minimum requirement, and doing so was considered premature. Server vendors can still use New I/O in their implementations if they like, but servlets won't be able to take full advantage of New I/O until they can get a true channel to communicate with the client.

Also not included are any rules on how HTTP and HTTPS interfaces on the same server should interoperate. Should sessions be the same, or must they differ? Should forward() and include() work, or should you use sendRedirect()? Perhaps these issues can be clarified in the next release.

Start serving up Servlet 2.4

As I've described in this article, Servlet 2.4 adds new minimum requirements, new methods to observe the request, new methods to handle the response, new internationalization support, several RequestDispatcher enhancements, new request listener classes, session clarifications, and a new Schema-based deployment descriptor as well as several new J2EE elements. The specification document overall has also been tightened to remove ambiguities that might interfere with cross-platform deployment. All in all, the spec includes four new classes and seven methods added to existing classes, one new constant variable, and one deprecated class. For a cheat sheet on moving from 2.3 to 2.4, see the sidebar below.

Jason Hunter is author of the book Java Servlet Programming, 2nd Edition (O'Reilly, 2001; ISBN: 0596000405) and coauthor of the new Java Enterprise Best Practices (O'Reilly, 2002; ISBN: 0596003846). He's an Apache Member and, as Apache's representative to the Java Community Process Executive Committee, he established a landmark agreement for open source Java. He's publisher of, an original contributor to Apache Tomcat, and a member of the expert groups responsible for Servlet/JSP and JAXP (Java API for XML Parsing) development. He cocreated the open source JDOM library to enable optimized Java and XML integration. Recently he designed and developed CountryHawk, a product that quickly determines a user's country based on their IP address.

Learn more about this topic

1 2 Page 2
Page 2 of 2