What Is New in Servlet 2.2
Servlet 2.2 introduced foundational changes that moved the specification towards a more component-based web application model. The key updates are summarized below.
| Category | Key Changes |
|---|---|
| Web Application Scope | Formalized the Web Application Archive (WAR) format and its deployment descriptor. |
| Deployment Descriptor | Introduced the <web-app> root element and DTD for structured configuration. |
| Session Management | Added the HttpSessionBindingListener interface for tracking session events. |
| Servlet Chaining | Provided a standard mechanism for one servlet to forward a request to another. |
| Error Handling | Added the ability to declare custom error pages in the deployment descriptor. |
How did Servlet 2.2 change web application packaging?
Servlet 2.2 formally defined the Web Application Archive (WAR) as the standard packaging unit. This meant all your application components--servlets, JSPs, static files, and the web.xml deployment descriptor--were bundled into a single, deployable .war file.
In practice, this was a huge win for portability. You could build a WAR on your development machine and be confident it would deploy and run the same way on any compliant application server. It established a clear contract between developers and container providers.
What new capabilities were added to the deployment descriptor?
The deployment descriptor, web.xml, became significantly more powerful and structured. The root element was standardized as <web-app> and it now used a Document Type Definition (DTD) for validation.
This structure allowed you to declaratively configure error pages using the new <error-page> element. You could map specific HTTP error codes or Java exception types to a custom page, centralizing error handling outside of servlet code.
How did session management improve in this version?
The HttpSessionBindingListener interface was introduced, giving objects fine-grained control over their life cycle within a session. An object placed into a session could now be notified when it was bound or unbound.
This matters because it allows for cleaner resource management. For example, a shopping cart object could automatically release database connections when the session expires or the user logs out, preventing potential resource leaks.
What was the significance of the new dispatching features?
Servlet 2.2 standardized a mechanism for request dispatching, both forward and include. This allowed for the creation of composite views and controller patterns, where one servlet could process a request and then forward it to another servlet or JSP for rendering.
This was a foundational step for the Model-View-Controller (MVC) patterns that would later become dominant in Java web frameworks. It moved applications away from the earlier model where a single servlet often handled an entire request end-to-end.
FAQ
Did Servlet 2.2 introduce the ServletContext?
No, the ServletContext existed before, but 2.2 strengthened its role. It became the central interface for accessing web application parameters, resources, and attributes within the scope of a single WAR file, reinforcing the application isolation concept.
Can I use custom error pages for specific exceptions?
Yes, this was a key addition. You could now map both HTTP error codes (404) and fully-qualified Java exception class names (java.sql.SQLException) to a specific error page URL in web.xml.
What is the purpose of HttpSessionBindingListener?
It allows an object to be notified when it is bound to or unbound from an HttpSession. The object itself implements the interface and defines the valueBound and valueUnbound methods, useful for managing resources tied to the session's lifecycle.
Is the WAR file structure from 2.2 still used today?
Absolutely. The basic WAR structure defined in Servlet 2.2--with a WEB-INF/ directory containing web.xml and classes//lib/ folders--is still the standard packaging format for Jakarta EE web applications decades later.
How did request dispatching work before this version?
Before standardization, dispatching behavior was often vendor-specific. Servlet 2.2 defined a uniform API (RequestDispatcher) for both including content and forwarding requests, which greatly improved code portability across different servlet containers.