By arungupta on Dec 18, 2012
Servlet 3.0 was released as part of Java EE 6 and made huge changes focused at ease-of-use. The idea was to leverage the latest language features such as annotations and generics and modernize how Servlets can be written. The web.xml was made as optional as possible. Servet 3.1 (JSR 340), scheduled to be part of Java EE 7, is an incremental release focusing on couple of key features and some clarifications in the specification.
The main features of Servlet 3.1 are explained below:
- Non-blocking I/O - Servlet 3.0 allowed asynchronous request
processing but only traditional I/O was permitted. This can
restrict scalability of your applications. Non-blocking I/O
allow to build scalable applications. TOTD
#188 provide more details about how non-blocking I/O can
be done using Servlet 3.1.
- HTTP protocol upgrade mechanism - Section
14.42 in the HTTP 1.1 specification (RFC 2616)
defines an upgrade mechanism that allows to transition from HTTP
1.1 to some other, incompatible protocol. The capabilities and
nature of the application-layer communication after the protocol
change is entirely dependent upon the new protocol chosen. After
an upgrade is negotiated between the client and the server, the
subsequent requests use the new chosen protocol for message
exchanges. A typical example is how WebSocket protocol is
upgraded from HTTP as described in Opening
Handshake section of RFC 6455.
The decision to upgrade is made in
Servlet.servicemethod. This is achieved by adding a new method:
HttpServletRequest.upgradeand two new interfaces:
TyrusHttpUpgradeHandler shows how WebSocket protocol upgrade is done in Tyrus (Reference Implementation for Java API for WebSocket).
- Security enhancements
- Applying run-as security roles to #init and #destroy methods
fixation attack by adding
HttpServletRequest.changeSessionIdand a new interface
HttpSessionIdListener. You can listen for any session id changes using these methods.
- Default security semantic for non-specified HTTP method in
- Clarifying the semantics if a parameter is specified in the
URI and payload
ServletResponse.resetclears any data that exists in the buffer as well as the status code, headers. In addition, Servlet 3.1 will also clears the state of calling
ServletResponse.setCharacterEncoding: Sets the character encoding (MIME charset) of the response being sent to the client, for example, to UTF-8.
- Relative protocol URL can be specified in
HttpServletResponse.sendRedirect. This will allow a URL to be specified without a scheme. That means instead of specifying "http://anotherhost.com/foo/bar.jsp" as a redirect address, "//anotherhost.com/foo/bar.jsp" can be specified. In this case the scheme of the corresponding request will be used.
- Clarification in
.getPartswithout multipart configuration.
- Clarification that
ServletContainerInitializeris independent of
metadata-completeand is instantiated per web application.
Each feature will be added to the JSR subject to EG approval. You
can share your feedback to email@example.com.
3.1 Public Review Candidate Downloads
- Servlet Specification Project
- JSR Expert Group Discussion Archive
- Java EE 7 Specification Status
Several features have already been integrated in GlassFish
4 Promoted Builds. Have you tried any of them ?
Here are some other Java EE 7 primers published so far:
- Concurrency Utilities for Java EE (JSR 236)
Whiteboard using WebSocket in GlassFish 4 (TOTD #189)
- Non-blocking I/O using Servlet 3.1 (TOTD #188)
- What's New in EJB 3.2 ?
- JPA 2.1 Schema Generation (TOTD #187)
- WebSocket Applications using Java (JSR 356)
- Jersey 2 in GlassFish 4 (TOTD #182)
- WebSocket and Java EE 7 (TOTD #181)
- Java API for JSON Processing (JSR 353)
2.0 Early Draft (JSR 343)
And of course, more on their way! Do you want to see any particular one first ?