An Overview of Servlet 3.0

JSR 315 (Servlet 3.0) is an update to the existing Servlet 2.5 specification. Servlet 3.0 is focussed on extensibility and web framework pluggability, aligning with the goals of Java EE 6. Ease of Development (EoD) will be supported using newer language features. A reference implementation is available in the GlassFish v3 nightly build. The public review contains:

• Pluggability
• EoD
• Async Support
• Security Enhancements
• Miscellaneous Changes

In this article we will bring you up to speed with what's happening with the Servlet 3.0 specification and give more detail on what is included.

Note: this article corresponds to the public review of the specification. As it is not yet final some things may change.

The Expert Group

Rajiv Mordani from Sun Microsystems is the specification lead with an expert group comprised of many of the most recognisable names in the Java community:

• Adobe Systems Inc.
• Apache Software Foundation
• BEA Systems
• Ericsson AB
• Google Inc.
• Hunter, Jason
• IBM
• Icesoft Technologies Inc
• NCsoft Corporation
• Oracle
• Pramati Technologies
• Prasanna, Dhanji R.
• SAP AG
• Ship, Howard M. Lewis
• Suleiman, Hani
• Sun Microsystems, Inc.
• Tmax Soft, Inc.
• Walker, Joe
• Wilkins, Gregory John

Pluggability

Due to the popularity of so many various web frameworks, Servlet 3.0 will make it easier to use and configure the developer's framework of choice. So if you want to add in Struts, or Spring Web Flow it will be easy to do so.

• Methods to add Servlets and Filters
  
  If a ServletContextListener is registered and wants to add a Servlet or Filter, then at the time of context initialization the event that is fired to the Listener can add Servlets and Filters to the context. The methods are addServlet and addFilter. For more details look for the javadocs at the JCP site at  http://jcp.org/aboutJava/communityprocess/pr/jsr315/index.html.

• Web fragments
  
  Instead of having just one monolithic web.xml that is used by the developer to declare servlets, filters and other configuration for using the framework, the framework can now include a web-fragment.xml with all it's configuration.
  
  A web-fragment is almost identical to the web.xml and can contain all the configuration needed by the framework in the META-INF directory of the framework's jar file. The container will use the information to assembe the descriptor for the application and the application needn't have to use any of the boilerplate configuration in their app for the framework. There are rules that are defined int the specification for conflict resolution, overriding and disabling fragment scanning. Along with the annotations which also can be in libraries the feature is very compelling not only for the developers that use frameworks but also for framework authors to be self sufficient in defining the configuration needed.
  
  The great benefit to this is that library providers can supply their own web.xml fragment for use in your webapp.

Ease of Development

Several new annotations have been defined for ease of development in Servlet 3.0, allowing you to write a Servlet without requiring a descriptor. These annotations reside in the javax.servlet.annotation package. Thanks to the addition of annotations, it is now possible to have Servlet, Filter and ServletContextListener in a war file without a web.xml.

It's important to point out that this makes the web.xml optional, rather than redundant. The web.xml may be user to override metadata specified via annotations.

Following discussions in the expert group and the community, it was decided that method level annotations were not to be added, so you keep the doGet, doPost methods and need to extend HttpServlet to use them.

Let's take a closer look at the annotations present in the Servlet 3.0 specification:

Servlet Annotation

In Servlet 3.0, servlet metadata can be specified using @WebServlet

@WebServlet(name="mytest", 
urlPatterns={"/myurl"}, 
initParams={ @InitParam(name="n1", value="v1"), @InitParam(name="n2", value="v2") }) 
public class TestServlet extends javax.servlet.http.HttpServlet { 
.... 
} 

TestServlet extends HttpServlet, while the meta data provided corresponds with the web.xml as follows:

Servlet Filter Annotation

ServletFilter meta data is specified using the @ServletFilter annotation

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { 
.... 
} 

public void destroy() { 
.... 
} 
} 

Servlet Context Listener Annotation

A ServletContextListener is simply marked with the @WebServletContextListener rather than needing to list it the web.xml file.

@WebServletContextListener 
public class TestServletContextListener implements javax.servlet.ServletContextListener { 
.... 
public void contextInitialized(ServletContextEvent sce) { 
.... 
} 

public void contextDestroyed(ServletContextEvent sce) { 
.... 
} 
} 

Async Support

The biggest change made in the specification is the addition of asynchronous processing. The main cases to cover were:

• Waiting for a resource to become available, such as JDBC or a call to a Web Service.

• Generating response asynchronously

• Using exisiting frameworks to generate responses after waiting the for asychronous operation to complete.

While the early draft had suspend and resume, the latest specification has two variations of the startAsync() method on ServletRequest.

One (startAsync() ) takes no parameters and initialises an AsyncContext with the original request and response. The ( startAsync() ) other takes a request and response as a parameter to initialise the AsyncContext with.

Servlets (@WebServlet) and Filters (@ServletFilter) that support asynchronous processing need to be annotated with the supportAsync attribute set. It is illegal to call startAsync if you have a Servlet or Filter that doesn't support asynchronous processing anywhere in the request processing chain.

The is also an AsyncListener that can be registered to get notification on timeout and completion of asynchronous processing of the request. This listener can be used to clean up resources if the wrapped request and response were used to create it's AsyncContext.

You can forward requests back to the container using the AsyncContext.forward(path) and AsyncContext.forward() methods so frameworks like JSP can create a response.

Security Enhancements

HTTPServletRequest will be enhanced with methods allowing programmatic login and logout, while ServletRequest will be able to force a login.The logout method will allow an application to reset the authentication state of a request without requiring the authentication to be bound to a HTTPSession.

Conclusion

The draft is just beginning to be implemented within Glassfish v3. The specification will be a required piece of Java EE 6 and hence all the features described above will be available in all Java EE 6 compatible containers. The presence of the various features described above will make developing Java web appications much easier.

Thanks to Rajiv Mordani for his input into this article, and to Shing Wai and Jan Luehe for the code snippets.