In my December 2008 blog, I strongly criticised the Servlet 3.0 JSR-315 process and the resulting Public Review Draft, describing it as a: “poor document and the product of a discordant expert group (EG) working within a flawed process” and of producing a “Frankenstein monster, cobbled together from eviscerated good ideas and misguided best intentions“.
Perhaps because of these harsh words (or more probably in spite of them), JSR-315 has become
significantly less discordant and some good technical progress has been
made.  While I remain somewhat concerned about the  process (Eg we have a Proposed Final Draft while some significant issues have yet to
be resolved and/or prototyped), I’d like to focus on the improved
spirit of the group and highlight some of the technical achievements that have
resulted.

Asychronous Servlets

JSR-315 has made significant progress on asynchronous servlets. The proposal, identified in my update on the Public Review Draft,
to define a specific dispatch type for async requests has been adopted
and that has resulted in a very workable asynchronous servlet proposal.
Once asynchronous dispatches were separated from normal dispatches,
this made irelevent most of the differing opinions about how filters
should apply and if forward semantics should apply. As a result the
methods previously named AsyncContext.forward(…) have now been renamed to AsyncContext.dispatch(…) and there is general agreement and support of the different asynchronous style of  usage possible with this API.
While
I think the final async proposal is far from perfect and perhaps over
complex, I don’t think any of the proposals (including my own) could
perfectly retrofit asynchronous behaviour to the servlet spec. The
benefit of the complexity is that the proposal well supports multiple
asynchronous paradigms and usage styles.  Most of my prior complaints
were more about specific usage styles and are thus not so important if
multiple styles are well supported.
Without a single imposed asynchronous model and
there will be significant
opportunity for frameworks to inovate in providing various asynchronous
models to the developer community. To this end, the Jetty continuation
style of jetty-6 has been updated in jetty-7 with ideas from
servlet-3.0 and should now be seen as a framework that builds upon the
servlet 3.0 capabilities.

Annotations and pluggability

Some of the key new features of servlet 3.0 is the increased support for ease of deployment with new ways to discovery, configure and deploy Filters and Servlets:

• Annotated filters and servlets may be deployed without the need for a web.xml entry.
• Jars may contain /META-INF/web-fragment.xml
  files with a subset of web.xml configuration.
• Programmatic
  configuration of Filters and Servlets from ServletContextListeners, which are potentially discovered in /META-INF/*.tld files within jars.

Since the Public Review Draft, an additional feature has been added for automatic discovery of webapplication configuration:

I believe these mechanisms are good improvements in the specification and I support their inclusion. I previously expressed concerns about the flexibility and optionality of their usage. Specifically that:

The Proposed Final Draft (8.2.2 & 8.2.3) has addressed all but the last of these concerns with the ability to specify in web.xml an absolute ordering of jars within WEB-INF/lib/ that allows jars to be excluded from the ordering. Each jar in WEB-INF/lib may be given a name by having a <name> element within a META-INF/web-fragment.xml file. The webapps WEB-INF/web.xml file can then have an <absolute-ordering> element that lists the fragment names in the order they will be applied, together with the optional <others/> element to specify if and when unnamed jars are included.
As well as my ordering concern, this feature addresses accidental deployment, as a deployer can list only known well trusted jars; and slow deployment, as an ordering can exclude jars that need not be scanned (other than to discover any web-fragment.xml file).
However, my lingering concern is that the PFD as written does not well express that Filters and Servlets cannot be configured by annotations or TLD listeners from jars excluded from the ordering, nor is it clear that ServletContainerInitializers can be excluded in this fashion.   For the purposes of avoiding accidental and/or slow deployment, it does not matter which of the mechanisms a jar uses for ease-of-deployment, exclusion should mean exclusion.  The responses from the servlet expert group have generally been in agreement with this, but I think the specification needs to be clearer. I have proposed that the following text be added to section 8.2.3:

Conclusion

Despite being in Proposed Final Draft, I think we are not quite at the conclusion stage. However excellent progress has been made and work is continuing. I hope that P in the current PFD is significant and that there will be at least one more draft before we are final. There is still a little time to send your own thoughts to to jsr-315-comments@jcp.org.
Sun Microsystems has invited me to participate in their technical session on Servlet 3.0 at Javaone, together with Rajiv Mordani and Jan Leuhe.  I’ll be presenting a section on the Asynchronous Servlets API and giving a demonstration that uses some ease-of-deployment features to deploy a webapp on glassfish using the Jetty asynchronous HTTP client  in a 3.0 asynchronous servlet. The session is TS-3790 “Java