Quantcast
Channel: Oracle Bloggers
Viewing all articles
Browse latest Browse all 19780

What's new in Servlet 3.1 ? - Java EE 7 moving forward

$
0
0

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.service method. This is achieved by adding a new method: HttpServletRequest.upgrade and two new interfaces: javax.servlet.http.HttpUpgradeHandler and javax.servlet.http.WebConnection.

    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
    • Session fixation attack by adding HttpServletRequest.changeSessionId and a new interface HttpSessionIdListener. You can listen for any session id changes using these methods.
    • Default security semantic for non-specified HTTP method in <security-constraint>
    • Clarifying the semantics if a parameter is specified in the URI and payload
  • Miscellaneous
    • ServletResponse.reset clears 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 getServletOutputStream or getWriter.
    • 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 HttpServletRequest.getPart and .getParts without multipart configuration.
    • Clarification that ServletContainerInitializer is independent of metadata-complete and is instantiated per web application.

A complete replay of What's New in Servlet 3.1: An Overview from JavaOne 2012 can be seen here (click on CON6793_mp4_6793_001 in Media).

Each feature will be added to the JSR subject to EG approval. You can share your feedback to users@servlet-spec.java.net.

Here are some more references for you:

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:


And of course, more on their way! Do you want to see any particular one first ?


Viewing all articles
Browse latest Browse all 19780

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>