Sun has submitted the Servlet 3.0 specification to the Java Community Process (JCP) as Java Specification Request (JSR) 315. High level goals include web framework pluggability, EoD (ease of development) features, async and Comet support, security, alignment with other specifications, and various other improvements. It is targeted for inclusion in Java EE 6 with a rough schedule putting final release in Q4 2008. Comments are due by July 2, 2007.
Here's an expanded version of the goals, from the JSR 315 Proposal:
- Web framework pluggability.
- Almost all of the Java based web frameworks build on top of servlets. Most web frameworks today plugin either through servlets or through web.xml. Annotations to define some of the servlets, listeners, filters will help in making this possible. Programatic access to web.xml and dynamic changes to configuration of a webapp are desired features. This JSR will aim to provide the ability to seamlessly plugin different web frameworks into web appplications.
- EOD
- Annotations - use of annotations for the declarative style of programming.
- As part of the EoD effort the goal is to have zero configuration for web applications. The deployment descriptors would be used to override configuration.
- Generics - Use generics in the API where possible.
- Use of other language enhancements where possible to improve the usability of the API.
- Async and Comet support
- Non-blocking input - The ability to receive data from a client without blocking if the data is slow arriving.
- Non-blocking output - The ability to send data to a client without blocking if the client or network is slow.
- Delay request handling - The comet style of Ajax web application can require that a request handling is delayed until either a timeout or an event has occurred. Delaying request handling is also useful if a remote/slow resource must be obtained before servicing the request or if access to a specific resource needs to be throttled to prevent too many simultaneous accesses.
- Delay response close - The comet style of Ajax web application can require that a response is held open to allow additional data to be sent when asynchronous events occur.
- Blocking - Non-blocking notification - The ability to notify push blocking or non-blocking events. Channels concept - The ability to subscribe to a channel and get asyncronous events from that channel. This implies being able to create, subscribe, unsubscribe and also apply some security restriction on who can join and who cannot.
- Security
- Ability to login / logout.
- Self registration.
- Alignment
- Misc
- Better welcome file support.
- ServletContextListener ordering.
- Container wide definition for init params.
- File upload - progress listener - where to store interim and final file.
- Clarifications of thread-safety issues.
Greg Wilkins, the main developer of Jetty and a supporting member of this JSR, takes issue with several of the goals under the "Async and Comet support" area. For both non-blocking input and output, he argues that the capabilities should be added to the container rather than exposed to the servlet developer. For delay request handling, he argues that suspend/resume semantics would be better and that they would also address the need for delay response close.
Existing projects will be used as a guide for the specification when appropriate. For example containers with current Comet support such as Grizzly, Tomcat, and Jetty will be reviewed when defining APIs for Comet. "Comet is a programming technique that enables web servers to send data to the client without having any need for the client to request it. It allows creation of event-driven web applications which are hosted in the browser." Also some existing web frameworks such as Shale, DWR, Spring Web Flow, and Wicket will be analyzed for web framework pluggability.