js|servlet| specification
Sun has submitted the SERVLET3.0 specification--JSR 315 (Java specification Request) to JCP (Java Community Process). Its advanced goals include the pluggable web framework, EoD (Ease of development--easy to develop) features, support for asynchrony and comet, security, integration with other specifications, and other improvements. It is ready to be included in Java EE 6, and the final version of Java EE 6 is released about 2008 4. It is expected that no comment will be made by July 2, 2007.
The following is a detailed version of these goals, from the JSR 315 proposal:
- Pluggable Web Frames
- Almost all java-based web frameworks are built on top of the servlet. Most web frameworks today are inserted either through a servlet or through web.xml. Using annotations (Annotation) to define the servlet, listener, and filter will make it (pluggable) possible. Program Access Web.xml and dynamically changing Web application configuration is the desired feature. The JSR will be dedicated to providing the ability to seamlessly insert different web frameworks into Web applications.
- EOD
- Annotations--use annotations as a declarative style for programming.
- Web application 0 Configuration is one of the EOD efforts. The deployment descriptor will be used to overwrite the configuration.
- Paradigm (generic)--use generics as much as possible in the API.
- Use other language enhancements where you might need to improve API availability.
- Supports asynchronous and comet
- Non-blocking input-receives data from the client, and no blocking occurs even when the data arrives slowly.
- Non-blocking output-sends data to the client, and does not block if the client or network is slow.
- Deferred request processing the comet style of--ajax Web applications can require a request processing to be deferred until a timeout or an event occurs. Deferred request processing is also useful for situations where a remote/lazy resource must be obtained before servicing the request, or if a particular resource is accessed, it needs to stifle some requests to prevent too many concurrent accesses.
- Deferred response closes the comet style of the--ajax Web application and can require that the response remain open to allow additional data to be sent when an asynchronous event is generated.
- Blocking/non-blocking notification-notifies a blocking or non-blocking event.
- Channel concept-the ability to subscribe to a channel and get asynchronous events from that channel. This means that you can create, subscribe to, unsubscribe from, and apply security restrictions such as who can join and who cannot.
- Safety
- Login/logout ability.
- Self registration.
- Combine
- Combination/requirements, from the rest JST JSR (JSR 311).
- Combination/demand, from JSF 2.0 JSR (JSR 134).
- Other
- Support for better welcome files (welcome file).
- Servletcontextlistener sort.
- The init parameter is defined in the container scope.
- File upload--Process listening--stores intermediate or final files.
- Clarify thread safety issues.
Greg Wilkins,jetty's main developer and the support member of this JSR are opposed to some of the goals under "support for Asynchrony and Comet". For non-blocking input and output, he believes that this ability should be added to the container rather than being exposed to the servlet developer. For deferred request processing, he thought that the suspend/restore semantics would be better, and that they would also result in a need for deferred response shutdown.
When appropriate, existing projects will be used as guides. For example, containers that currently support comet, such as Grizzly, Tomcat, and jetty, are reviewed (review) when the API is defined for comet. "Comet is a programming technique that allows a Web server to send data to clients without any client requests." It allows you to create event-driven Web applications that are hosted in a browser. "For the pluggable web framework, existing Web frameworks such as shale, DWR, Spring Web flow, and wiched will also be analyzed."
