Rajiv Mordani's Blog

Servlet 3.0 - from the source

• Ease of Development (Eod)

  In the early draft we added the annotations that allowed you to essentially write a Servlet as a POJO. However after some discussions in the expert group and feedback from some folks in the community, we decided to actually remove the method level annotations like @GET, @POST etc and keep the doGet, doPost method contracts and require extending an HttpServlet. However the top level annotations which are renamed for better usage in applications still exist. The @WebServlet annotation is used to declare a servlet, @ServletFilter to declare a filter and @WebServletContextListener to define ServletContextListeners. In addition to these annotations, other annotations like @Resource, which have been supported in web applications since Servlet 2.5 will continue to work as before. As an example a servlet declaration using Servlet 3.0 will now look like -

  @WebServlet("/foo")
  public class MyServlet extends HttpServlet {
      public void doGet(...) {
          ....
      }
  }
  

• Pluggability

  Web frameworks built on top of servlets are very popular for developers and there are a lot of them that address various different problems. In order to better support frameworks for developers writing webapps we are adding ways in the servlet 3.0 specification to make it easier to use and configure frameworks of their choice. There are a couple of ways that enable pluggability -
  • 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 when the specification is published.
  • Web.xml 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.

• Asynchronous processing

  • This is the biggest change that we have made in the servlet 3.0 specification. In the early draft we had suspend and resume and certain semantics that were defined. However after the early draft the expert group had a lot of discussions on solving various use cases for asynchronous processing and the changes that are made to the specification in this area now also address the various use cases.
  • Instead of suspend and resume we now have a startAsync method on request and there are two variations of these. One that takes a request and response in which case the AsyncContext that is created when you call startAsync will be initialized with the request and response passed in. The other is a startAsync() that takes no parameters, in which case the AsyncContext is initialized with the original request and response. Also the Servlets and Filters that support asynchronous processing must be annotated appropriately with asyncSupport attribute set. It is illegal to call startAsync if anywhere in the request processing chain you have have a servlet or a filter that does not support async.
  • In addition to the AsyncContext there is also an AsyncListener that can be registered to get notifications on timeout and completion of async processing of a request. The event listener can be used to clean up resources if wrapped request and responses were used to initialize the AsyncContext.

Comments

• Just one simple question :) What will be servlets good for since JAX-RS makes easier lot of servlet use cases? It looks like it will become lowend technology for framework creators only just like JDBC.

  Posted by: musketyr85 on December 02, 2008 at 11:46 PM

• musketyr85 - A LOT of frameworks build on the web container. JAX-RS also builds on the servlet container as one of the containers in the Java EE platform. So adding functionality to the underlying container will enable frameworks which will make developers lives easier.

  - Rajiv

  Posted by: mode on December 03, 2008 at 12:56 AM

• Sure. That are frameworks creators who will use servlets, but my queston was more on ordinal developers who don't write any frameworks.
  I was just curious whether you or your colleagues know some use cases where end user programmer would say "Hey, this cannot be done so easy with JAX-RS let's do it with old good servlet!"

  Posted by: musketyr85 on December 03, 2008 at 02:51 AM

• is startAsync to be used for comet a/ the asyncContext?

  Not resume ?

  Is there a draft document to look over?
  Sample code?

  Posted by: netsql on December 03, 2008 at 08:56 AM

• Are you guys planing to (finally) add a unified api/framework for uploads? Today... every damn web framework does it on its own... Please fix that

  Posted by: mwessendorf on December 04, 2008 at 04:48 AM

• Regarding the start async proposal, I think this is a much better concept than start resume. I have written HTTP server which uses a similar concept, however asynchronous processing is transparent from the outset.

  http://www.simpleframework.org/

  This form of processing also opens up the servlet container to parallelize requests on the same pipeline. As it allows HTTP request completion to drive dispatch of the next request, rather than service completion, and without any greater buffering demands. Performance is also much better than the conventional Servlet service model.

  http://www.simpleframework.org/performance/comparison.php

  Posted by: gallagher_niall on December 04, 2008 at 05:56 AM

• musketyr85: I recently was at a JUG and queriied the attendees to see how many people are still writing servlets and was quite surprised to see the number. However to answer your question - for JAX-RS to be able to support async for example one way it could do it is via using the underlying functionality in the container. If JAX-RS does not have any support for async (as is the case today) then what does a developer do?

  Posted by: mode on December 04, 2008 at 10:48 AM

• netsql: I will soon be writing an entry describing the async API. A lot of people have asked me the same question as you.

  Posted by: mode on December 04, 2008 at 10:49 AM

• mwessendorf: It is still in the plan. We hope to have it in the proposed final draft of the spec.

  Posted by: mode on December 04, 2008 at 10:50 AM

• Actually, the real question is what incremental features could be added to the base Servlet API so that a developer could choose "raw" servlets instead of any framework whatsoever?

  For example, the HTTP Method and URL mapping feature of JAX-RS, but, say, without the content-type matching and conversion features.
  

  Posted by: whartung on December 04, 2008 at 02:03 PM

• So, it looks like we're still left without a usable security feature?

  Posted by: kito75 on December 08, 2008 at 03:59 PM

• kito75: Security enhancements are planned for the next release. However can you send me email to be more specific about "a usable security feature"?
  

  Posted by: mode on December 08, 2008 at 04:45 PM

• whartung: Can you be more specific about the HTTP method and URL mapping? Do you mean the uri templating support?

  Posted by: mode on December 08, 2008 at 04:46 PM

This work is licensed under a Creative Commons License.