Skip navigation
1 2 Previous Next

mode

25 posts
The JSR for the next revision of Servlet specification - Servlet 3.1 is approved and we are now in the process of forming the expert group. If you would like to contribute to the development of the next version of the servlet specification, please nominate yourself and, if possible, please explain how you plan to contribute to the specification. If you would like to track the progress of the spec, and see the folowings of the JSR, the spec will now be done using java.net infrastructure. Anyone can sign up to the users mailing list of the servlet-spec.java.net project and will be able to see the proceedings of the expert group mailing list. Please go the JCP site here and click on "I would iike to join this Expert Group". Please make sure that your JSPA is up-to-date. Feel free to provide feedback directly to me if you rather prefer that.  
Jan Luehe, Greg Wilkins and I did a talk on Servlet 3.0 at JavaOne yesterday. Am attaching the slides from the talk for those that didn't make it or did make it and want a copy of the slides :).  
The proposed final draft of the Servlet 3.0 specification is now available at the JCP site . In addition to the specification, also refer to Shing Wai's blog describing in detail the ordering solution for fragments and the use of security annotations.  
It's been a while since my last update. However I am pleased to report that the Proposed Final Draft (PFD) of Servlet 3.0 is now been handed off to the JCP. Some highlights of what is in the PFD draft - 
  • The issues around Async have been worked out and Greg will also be posting an update to his last set of comments. Basically there were some tweaks to the APIs and semantics of the proposal. However the proposal itself hasn't changed drastically. It has been implemented in GlassFish and I believe also in Jetty 7.0 pre release build.
  • We now have an ordering solution for Servlets, Filters and Listeners that also allows users to control what jar files are looked up based on the pluggability feature described previously.
  • In addition to the pluggability via fragments, annotations, we also introduced the concept ofServletContainerInitializer which allows you to plugin providers based on either annotations or classes that a particular class implements. For example when plugging in JAX-WS into a web container to support web services, today most implementations require you to use a proprietary descriptor (unless you are writing a JSR 109 style web service) for using the web service library in a web container. I will provide more details of how framework authors can use the ServletContainerInitializer in a separate blog soon to follow.
  • Ability to load static resources and JSPs from a jar file. This feature enables users to bundle shared resources in a jar file in a special directory - META-INF/resources. When included in the WEB-INF/lib directory of the webapp, if the container does not find a particular resource in the root directory of the webapp, it will look at the jar files in the WEB-INF/lib to see if the resource is bundled in META-INF/resources of any jar file and serve it up.
  • Security enhancements - programmatic authenticate, login and logout support. Support for @RolesAllowed, @PermitAll, @DenyAll annotations in the web container.
  • Updated existing APIs to use generics where possible in a backward compatible manner.
  • Default error pages for error codes.
  • Clarified welcome files.
  • File upload - We have a basic solution in place, which we will build upon in a future release of the Servlet specification.
Look out for the specification release (I will post an update when relased) and provide feedback. 

If you are attending JavaOne this year, Jan Luehe (from Sun), Greg Wilkins(Jetty / Webtide) and I will be presenting the Servlet 3.0 features in a technical session - TS-3790 "Java

Someone just pointed me to Greg Wilkin's latest blog entry. I tried posting my response in his comments however it was tagged as spam and not displayed. So I am making the comments available her.
I am REALLY surprised at this blog. Let me try to answer some of these questions in the public forum. 

"This public draft of the servlet-3.0 represents a thought experiment in API design unhindered by the complexities of implementation, trial usage or community feedback."

An implementation of this is available in GlassFish in the trunk.

"As a member of this Expert Group, I've been as guilty as the other members by looking at uncompiled/untested APIs and believing them to solve the issues at hand, only to later discover that these APIs prove to be unworkable when implemented and/or used."

The APIs are implementable. Take a look at the GlassFish trunk.

"Requests for test implementations have been denied"

I never saw a request from you. In fact YOU offered to implement some of the features in Jetty and showcase the technology.

"Any feedback received on the jsr-315-comments@jcp.org list have been kept private and not shared even with the EG, despite several requests. "

Please check your email carefully. All the mails that I have received I have forwarded to the EG. Also I never saw a request from you to share feedback that is received.

"EG members and community feedback raised concerns about the security and ordering aspects of the automatic deployment possible with the Annotations and Pluggability feature (see below). The response was not the "How can we address these concerns" discussion that I was expecting. Instead the response was more along the lines of Obe-wan Kenobi saying "these are not the concerns you are looking for. Move along!" "

Looking into the security concerns we introduced the enabled, flag that can enable and disable servlets. Also like some of the other EG members pointed out that if a user does not know how a framework works he shouldn't be using it in the first place. Or if a framework is authored badly then it shouldn't be used in the first place. The problem is that you never get PAST what YOU suggest as a solution and YOU always think of solutions keeping that in mind.

"Alternately, some unsubstantiated requirements (eg. wrapped asynchronous requests) have been included at a late stage without any use-cases or user demand, which have introduced whole new dimensions of complexity so that discussions have been ratholed for months chasing marginal edge cases."

I don't believe that you say this. Late in the game and we rat holed more on the use case that you had as opposed to the wrapped use case. In fact if you remember, members of the EG were opposed to the re-dispatch semantics that we had. So please don't provide an incorrect picture to the people reading your blogs.

"Accidental Deployment"

We have had no such experience with the use of annotations in JAX-WS, EJB, and other places in the Java EE platform. Also there are ways to turn off the accidental deployment - use the enable flag to enable / disable servlets. Are you even paying attention to the solutions that the EG is working on providing?

"Slow Deployment"

Please provide numbers of how deployment is slowed down. If you just "feel" that deployment will slow down significantly it isn't good enough. In the Java EE 5 days we did the analysis of scanning of annotations and the result was that we didn't see any significant slowing down. I can share the numbers in the EG if you are REALLY interested in the problem.

"Ordering"

Yes this is a problem for the fragments. However there is a solution to use the web.xml to do the ordering. Also your blog seems to be getting confusing. On one hand you criticize the feature of pluggability with accidental deployment, slowing down deployment with scanning, and on the other hand you want to use the feature and not define everything in the web.xml? Make up your mind what you want? Use the feature or just keep using the web.xml as before.

As for the async rebuttal and everything else about the Async proposal just a few quotes from emails to the EG.

Quoting you -
"Excellent! This proposal is definitely better than suspend/resume!"

Quoting another EG member -
"Greg, I think you're being too aggressive. I do realize you care about the subject. I think Rajiv's design is now quite fine, so using the "flood until he agrees to my stuff" tactic is unfair. From what I've seen many have stated a preference for his design (I have a coworker who's also not very comfortable with your design). And the adapted code example looks good to me too."

You have just taken this tactic outside the EG now because the EG members were starting to point this out to you.

I am really starting to agree with Bill Burke about the statement he made in his blog.

Update:

Maxim MoldenHauer, the IBM representative on the EG has also blogged on the issue.  
mode

Servlet 3.0 webinar Blog

Posted by mode Dec 10, 2008
I will be presenting 3.0 in a webinar on December 18th. For details and logistics about the webinar go to http://wikis.sun.com/display/TheAquarium/Servlet3.0. If you would like to learn about the new features in servlet 3.0 I would definitely encourage you to attend the webinar.  
After the last couple of entries I have gotten requests for more details on how the async works. So I decided to write this up in a blog to share what the async support looks like in the Servlet 3.0 public review draft. 

There are a couple of use cases that we are trying to handle with the async support in Servlet 3.0 -

  • Wait for a resource to become available (JDBC, call to webservice)
  • Generate response asynchronously
  • Use the existing frameworks to generate responses after waiting for the async operation to complete
Keeping this in mind the API that the expert group has agreed upon for async is as follows. 
  • Annotation attributes in the @WebServlet and@ServletFilter annotations that indicates if a Servlet or a Filter supports async. The attribute isasyncSupported.
  • To initiate an async operation there are methods onServletRequest - startAsync(req, res) andstartAsync() (difference described below).
  • Call to startAsync returns anAsyncContext initialized with the request and response objects passed to the startAsync call.
  • AsyncContext.forward(path) andAsyncContext.forward() that forwards the request back to the container so you can use frameworks like JSP to generate the response.
  • AsyncContext.complete() indicates that the developer is done processing the request and generating the appropriate response.
  • There are a few more methods in ServletRequestlike isAsyncSupported and isAsyncStartedthat can be used by applications to determine if async operations are supported or started.
  • There is also a new listener - AsyncListener that applications can use to get notified of when async processing is completed or if a timeout occurs.
To initiate async processing there are two methods available - one that takes a request and response (startAsync(req, res) ) and one that does not take any parameters (startAsync()). The difference between the two method signatures is that the startAsync() with no parameters implicitly uses the original request and response while the startAsync(req, res) uses the request and response objects passed in. The request and response passed in can be wrapped by filters or other servlets earlier in the request processing chain. The AsyncContext is initialized appropriately with the request and response depending on the method used. Caution must be taken when wrapping the response and calling the no arguments startAsync(). If any data has been written to the wrapped response and not flushed to the underlying response stream you could lose the data. 

Similarly after the async processing is over if you choose to forward the request back to run in the context of the web container there are three methods that are available in the AsyncContext that enable this. forward(path), forward(ServletContext, path) and forward().

  • forward() no args forwards back to the "original url" or if a forward (AsyncContext or RequestDispatcher forward) has occured after an async context has been initialized then the no args forward will forward to the path that was used by the AsyncContext / RequestDispatcher to forward to.
  • forward(path) forwards to the path relative to the context of the request
  • forward(ServletContext, path) forwards to the path relative to the context specified. Below is an example that shows a simple web application that is waiting for a webservice call to return and then rendering the response. Note the actual code for calling the web service itself is not included. 
    @WebServlet("/foo" asyncSupported=true)
    public class MyServlet extends HttpServlet {
        public void doGet(HttpServletRequest req, HttpServletResponse res) {
            ...
            AsyncContext aCtx = request.startAsync(req, res);
            ScheduledThreadPoolExecutor executor = new ThreadPoolExecutor(10);
            executor.execute(new AsyncWebService(aCtx));
        }
    }
    
    public class AsyncWebService implements Runnable {
        AsyncContext ctx;
        public AsyncWebService(AsyncContext ctx) {
             this.ctx = ctx;
        }
        public void run() {
            // Invoke web service and save result in request attribute
            // Forward the request to render the result to a JSP. 
            ctx.forward("/render.jsp"); 
        }
    }
    
    If you would like to try it out use the nightly build of the GlassFish trunk and post any issues that you run into at webtier@glassfish.dev.java.netwhich the GlassFish webtier team monitors closely.
Since the Early draft of the specification for Servlet 3.0 (JSR 315) the expert group has been working on refining and improving the specificaiton in a couple of areas - Ease of Development (EoD), pluggability and asynchronous support. Below is a description of things that are in the soon to be available public review to enable each of these features. 
  • 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.
Please take a look at the specification when it is published on the jcp.org website and send us your feedback at jsr-315-comments@jcp.org.
An early access implementation of some of the features are available in the GlassFish nightly build. For further discussion please post your questions about the implementation to webtier@glassfish.dev.java.net
Jetty 7 pre-release also has some of the features implemented for those interested.
Look for more blogs about these features from my colleagues Shing Wai and Jan Luehe on specifics of some of the implementation.  
It's been a while since I gave an update about servlet 3.0. However while I haven't been blogging we at the expert group are working through refining and making the specification better for the web community. We are in the process of making the Public Review available and was waiting to push out a blog after that. However I have seen a few people write about the 3.0 work based on the Early Draft Review (EDR) (like http://www.theserverside.com/tt/tss)and thought it was best to clarify this so that there isn't any confusion arising from this.
The specification has evolved since the EDR and things have changed. the EDR is an early review to get feedback from the community. It is not the final version of the specification. Some of the changes that have happened since the EDR are : 
  1. The annotations to define the http methods (GET, POST, etc) are no longer there. One would still have the extend HttpServlet and use the contract specified there. The top level annotations for declaring a Servlet and Filter are still there and that the expert group still feels is needed and useful to the community. However they are no longer POJOs.
  2. The fragments have evolved since the EDR and the rules for merging the fragments have been specified in the upcoming Public Review.
  3. The asynchronous (or what people are referring to as continuations) has also evolved. First off the notion of continuations is different than async. We now have what the expert group considers a cleaner proposal that will be able to handle a lot more use cases.

As an example of some of the things that you will have to do as a developer - 
@WebServlet("/foo")
public class MyServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) {
        //....
    }
}
The suspend and resume APIs are no longer there. Instead we have a startAsync on request that returns an AsyncContext that the users then can use to do async operations and not have to block a thread to complete the processing.
These are just a sneak peak at what is coming and would encourage users to look at the public review when it becomes avaialble at the jcp.org site and send feedback. In the mean time I also encourage people writing articles / blogs about servlet 3.0 to contact us atjsr-315-comments@jcp.org to get an update from the expert group so they can reflect the status of the specification correctly. I will be writing a more detailed blog with more samples show casing the features in the servlet 3.0 specification in the coming days so stay tuned.  
We now have a dedicated irc channel for the GlassFish webtier where you can chat with the engineering team members. It is on irc.freenode.net. For help on how to use irc, the clients for the various OS click here. There is also a FAQ for freenode that you should refer to for any questions regarding usage of freenode. It is located here. Update: Someone pointed out that I forgot to put the channel name - it is glassfish-webtier.  
We now have an aggregated feed for all webtier related blogs - http://feeds.feedburner.com/GlassFish-webtier.  
We now have a mailing list - webtier@glassfish.dev.java.netand forumdedicated to discuss user issues for the webtier of GlassFish. The intent is to use the mailing list and forum for discussing the webtier technologies including Servlets, JSP, JSF, JSTL, Grizzly and scripting support in GlassFish and build a community that focuses on webtier of the Java EE platform. Cross-posting from one to the other is still not working but it should be pretty soon. Please consider joining the mailing list or use the forum.  
In my previous post I described some of the pluggability mechanism being added to the servlet 3.0 specification. One of the issues that I didn't touch upon in detail was how the annotations and web-fragments are processed and how can one override / turn off the auto scanning of annotations and web-fragments. 

Greg Wilkins from Webtide bloggedabout the pluggability mechanism and raised an issue with the auto-scanning. Hopefully this blog will make the argument for the simple scanning of annotations and web-fragments and argue against the case of having a more flexible scheme in this release of the servlet specification.

I will start with the annotation case first and then talk about the web-fragments. When you use annotations to declare servlets and Filters then you must have a url-mapping / FilterMapping attribute on the corresponding servlet / Filter. In this way there is no convention by which a servlet is exposed without having an explicit mapping. Also , as with the rest of the Java EE platform, specifically technologies like EJB and Web Services, the deployment descriptor is used to override information that is specified via annotations. So if you have a servlet that is declared via annotations during development and now you need to change one attribute of the servlet when you go from development to production, you don't need to modify the code. Instead you override the configuration using the web.xml file. In the example below I show how this can be used -

@Servlet(url-mapping="/foo")
public class MyServlet {
    @GET
    public void handleGet(HttpServletRequest req, HttpServletResponse res) {
         ...
     }
}
At deployment time say you want to override the url-mapping for the servlet defined above. The way you would do that would be by defining the new mapping for the servlet in the web.xml as shown below - 
<web-app>
  <servlet-mapping>
    <servlet-name>
      MyServlet
    </servlet-name>
    <url-pattern>
      /MyApp
    </url-pattern>
  </servlet-mapping>
</web-app>

If you didn't want any of the annotations to be processed at all by the container and wanted to specify all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform, we have the metadata-complete element in the descriptor. If the element is present and set to "true" then the container will not process any annotations and just use the configuration specified in the descriptor. This provides a way disable the auto-scanning for those that have concerns about performance, and security. This is consistent with what we have today in Java EE 5 platform and has worked well with EJBs and JAX-WS (Web Services APIs). We have not received any negative feedback about security and performance being an issue. Web Services are endpoints that are exposed on the web so the argument someone makes about there not being a security hole in EJB does not stand true for Web Services.

The second issue is about auto-scanning of web-fragments. The early draft of the specification says that the container needs to process web-fragments and make available the servlets, filters an listeners defined via the fragments. As discussed in my earlier post, this helps with use of frameworks. Currently the early draft of the specification says that the same flag - metadata-complete controls both the scanning of annotations and fragments. I still think that is sufficient for the developers. However during JavaOne we had an expert group face-to-face meeting and discussed the possibility of having another flag to control the scanning of web fragments and use the metadata-complete just to control scanning of annotations. Again similar to metadata-complete this flag would control whether to scan for web-fragments or not. If you choose not to scan the web-fragments then you would need to specify the entire metadata that you need in in the web.xml of the application, a-la metadata-complete :). For those that have major security concerns this would probably be the route to go because even if you do have the include mechanism there would be no way to specify just one servlet from the jar file. The container would still scan for all the servlets, filters and listeners from the framework available. The concept of "trusting" certain frameworks doesn't seem to solve the problem. Let's take Spring for example - if you choose Spring as the framework but didn't want one of the servlets defined in Spring to be available. The include mechanism would not work for you. You would have to fall back on defining everything in the web.xml of the application anyways. The benefit that the include proposal from Greg Wilkins is very little specially if the main concern is that servlets and filters are being exposed without the user intending to do so. I think that it is the problem of the framework developer and not the user of the framework to make sure that they don't expose certain types of components. By using a flag to control scanning you can effectively get what the include mechanism provides except you don't get partial scanning of only a certain set of jars. The include mechanism would probably only make the descriptor more verbose in having to list the jars you want scanned.

Another mechanism that came up during the face-to-face which hasn't been still talked about in the expert group is the concept of disabling servlets and filters in the application's web.xml. For example we could have in the application's web.xml the following -

  <servlet>
    <servlet-name>FrameworkServlet</servlet-name>
    <enabled>false</enabled>
  </servlet>

This way some of the servlets that aren't needed in production can be disabled via the main web.xml of the application and the security issue can be mitigated while keeping things simple.  
mode

Servlet 3.0 pluggability Blog

Posted by mode May 13, 2008
In my earlier post I gave an overview of the things that are being worked upon in Servlet 3.0. This post focuses on one of the areas that the expert group has been working on - pluggability.

 

Pluggability

There are a lot of frameworks / libraries that are built on top of the servlet container. Most frameworks today require you to configure a servlet, filter or listener in the application's web.xml in addition to including it as a dependency in the WEB-INF/lib directory. Today in a servlet container the application has one monolithic web.xml that defines all the deployment artifacts for the application, including the dependencies of the application on the framework components. In it's current state, a developer must go through the documentation of each framework that it depends on and declare the appropriate servlets, filters, Listeners, etc. The goal is to make it possible to use frameworks without having to worry about any additional configuration. 

To overcome this issue in servlet 3.0 we are adding a new feature that allows having more than one web.xml, or as it is being referred in the specification as web fragments. A framework can define it's own web.xml that declares the necessary components for the framework that is then included for use in the web applicaton. At deployment the container is responsible for discovering the web.xml fragments and processing them. A new element is being added to the schema for web applications - web-fragment that can define servlets, filters listeners. Below is a simple example of such a fragment.

<web-fragment>
  <servlet>
    <servlet-name>welcome</servlet-name>
    <servlet-class>
      WelcomeServlet
    </servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>welcome</servlet-name>
    <url-pattern>/Welcome</url-pattern>
  </servlet-mapping>
...
</web-fragment>

The above fragment would be included in the META-INF directory of the framework jar file. 

In addition to changes to modularize the web.xml there are also annotations being defined to declare servlets (@Servlet), filters (@ServletFilter) and the annotations have all the attributes defined to make web.xml optional. These attributes contain information like url-mapping, init-params and other information that would typically be defined in the deployment descriptor. This way Servlets, filters etc can be defined entirely using annotations and would be picked up from the WEB-INF/classes or WEB-INF/lib directory.

Along with the changes mentioned above there are few new APIs to also allow programmatic addition of Servlets and Filters at start up time of an application. API changes for adding configuration are added to the ServletContext class and are listed here below:

ServletContext: 
    addServlet 
    addServletMapping 
    addFilter 
    addFilterMapping 
Below is an example that shows how the APIs defined in ServletContext can be used. 
@ServletContextListener
public class MyListener {
    public void contextInitialized (ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        sc.addServlet("myServlet", 
                      "Sample servlet", 
                      "foo.bar.MyServlet", 
                       null, -1);

        sc.addServletMapping("myServlet", 
                             new String[] {"/urlpattern/*"});
    }
}
@ServletContextListener
public class MyListener {
    public void contextInitialized (ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        sc.addFilter("myFilter", 
                     "Sample Filter", 
                     "foo.bar.MyFilter", 
                      null);

        sc.addFilterMapping("myFilter", 
                             new String[] {"/urlpattern/*"},                         
                           
Update: The early draft of the specification is now available at the JCP site. Click here to get to the draft. It's been a while since I put a post on the blog so I thought I would take this opportunity to give an update on the servlet 3.0 specification. The expert group has been working through to enhance the APIs in the servlet specification. This blog is to give an update to the developers about the features that are proposed for the upcoming early draft of the specification. The main areas covered so far by the expert group are 
  • Pluggability and extensibility
  • Ease of development
  • Async support
  • Security enhancements
  • Some enhancements to the existing APIs.

Pluggability and extensibility

In keeping with one of the main theme for Java EE 6, the goal of this requirement is provide more extension points in the servlet container to allow developers to easily use frameworks / libraries by "just dropping" a jar file in the application classpath and not require any additional configuration in the application. Today, in a servlet container the application has one monolithic web.xml that defines all the deployment artifacts for the application, including the dependencies of the application on the framework components. In it's current state, a developer must go through the documentation of each framework that it depends on and declare the appropriate servlets, filters, Listeners, etc. To overcome this issue in servlet 3.0 we are adding a new feature that allows having more than one web.xml, or as it is being referred in the specification as web fragments. A framework can define it's own web.xml that declares the necessary components for the framework that is then included for use in the web applicaton. It is the job of the container to assemble all the fragments at deployment / runtime of the application.

Along with the changes mentioned above there are few new APIs to also allow programmatic addition of Servlets and Filters at start up time of an application. API changes for configuration addition:
ServletContext: addServlet, addServletMapping, addFilter, addFilterMapping

Ease of Development

In servlet 3.0 one of the areas of focus is ease of development. The servlet 3.0 API is making use of annotations to enable a declarative style of programming for components of a web application. For example - to define a servlet you would use the following piece of code -
package samples;
import javax.servlet.http.annotation.*;

@Servlet(urlMappings={"/foo"})
public class SimpleSample {

}
The use of annotations makes web.xml optional and a developer does not really need to use it unless they want to change some configuration without changing code - for example at deployment time. Also, as with all the other parts of the Java EE platform, the descriptor always overrides the metadata provided via use of annotations. 

Async support

The initial proposal for Async servlet support came from Greg Wilkins from Webtide and has been discussed and refined in the expert group. Support for async servlets allows you to suspend and resume request processing and enable and disable the response depending on the need of the application. A good use case of this servlet is in writing comet style applications. API changes for async support:
ServletRequest: suspend, resume, complete, isSuspended, isResumed, isTimeout, isInitial
ServletResponse: disable, enable, isDisabled
ServletRequestListener: requestSuspended, requestResumed, requestCompleted
 

Security enhancements

While this is not in the early draft of the specification as it needs some more discussion in the expert group, I thought I would give a sneak preview of what might be in the next draft of the specification. Ron Monzillo from Sun who is a security expert and has done work on many of the security related JSRs proposed the addition of methods to HttpServletRequest and HttpSession to support programmatic login and logout. API changes for login / logout support:
HttpServletRequest: login, logout
HttpSession:logout
 

Enhancements to existing APIs

A few areas of the current API have been enhanced that will help in developer productivity. Listed below are some of them - 
  • Ability to get a ServletContext and a Response object from the Request object. To get a Context (to maybe get context information or to get a RequestDispatcher for example) today you need to create a HttpSession object just to get a reference to a Context object. With the addition of the new APIs you can now get the Context and the associated Response from the ServletRequest. API changes for getting a Context and Response:
    ServletRequest: getServletContext, getServletResponse
  • Mark a cookie as an HttpOnly cookie. By setting a cookie to be an HttpOnly cookie you prevent client side scripting code from getting access to the cookie. Most modern browsers support this feature and it helps mitigate some kinds of cross-site scripting attacks. API changes to support HttpOnlyCookie:
    Cookie: setHttpOnly, isHttpOnly

Note: For details about all the API changes look at the javadocs (once the spec is available from the jcp website). The exact method signatures aren't duplicated here. Instead just the names are here to give an idea of the kind of changes.