DeCare Systems Ireland Blog

JavaOne 2008 / Day 3

The upcoming version of the Java Servlet Specification was covered in a session called “Java Servlet 3.0 API, What’s New and Exciting” presented by Rajiv Mordani from Sun.

Java Servlet 3.0 Specification, the spec that the next generation Servlet Engines will implement, will be included in Java EE 6. Sun submitted the specification to the JCP (Java Community Process) in June 2007. Its main goals include:
- Pluggability and extensibility
- Ease of development (EoD)
- Async and Comet support
- Enhanced Security

The spec is currently in early draft state so it can still change. If you have anything to say, it’s the right time to talk to the 22-member committee to give them the feedback they’re looking for. All of this is covered under the JSR 315.

Pluggability and Extensibility

The pluggability and extensibility revolves around the modularization of the web.xml file. The new spec defines a new element called a “web-fragment“. It is also an addition to the web application schema:

<web-fragment>

  <servlet>

    <servlet-name>fooBarServlet</servlet-name>

    <servlet-class>

      FooBarServlet

    </servlet-class>

  </servlet>

  <servlet-mapping>

    <servlet-name>fooBarServlet</servlet-name>

    <url-pattern>/foo</url-pattern>

  </servlet-mapping>

  ...

</web-fragment>

Basically, that’s a web module that can define servlet, servlet-mappings etc. just as in current web.xml files. It turns out that these web-fragments are discovered using auto-discovery. The discovery mechanism is implementation-specific, however the whole WEB-INF folder is scanned. At this point, the first question that comes to my mind is “why not to have a static inclusion/exclusion mechanism (as well)?”

Ease of Development (EoD)

To improve the ease of development, the new spec tries to use the Java SE 5 features. Especially… (Yes! You guessed it right!)… More annotations. So, the deployment descriptor becomes optional thanks to the use of annotations. I’m not a huge fan of annotations. They fit well some situations, such as an MVC framework defining a controller (à la Spring MVC), however I have some concerns about the new Servlet 3.0 annotations. I’ll voice my worries in a few minutes.

To start with, we’ll be able to define a Servlet with @Servlet annotation and we’ll be able to define the HTTP methods with the following annotations: @GET, @POST, @PUT, @DELETE, @HEAD.

To illustrate the use of the new annotations with an example, that’s how you would create a servlet:

@Servlet(urlMapping("/foo"))

Or

@Servlet(urlMapping = {"/foo", "/bar2"}, name = "fooBarServlet")

Following the same principle, you can work with filters or the servlet context using the annotations above:
- @ServletFilter
- @FilterMapping
- @ServletContextListener

Hold on a second! What was wrong with the interface approach? Is that just having annotations for the sake of having them? Here’s a question that comes to my mind immediately: “What if I annotate two methods with @GET?” or “Can I annotate the same method with @GET and @POST“? “Are those enforced at compile-time?”

web.xml is optional but it’s still the master configuration. So you can override your annotations in your web.xml.

Mordani also mentioned “convention over configuration” however I didn’t see him giving an example about this. So, I’m not sure in what areas we’re going to have conventions…

Async Servlet Support (Comet Support)

Probably the most important new feature is the Asynchronous Servlet support. This is very important for Comet applications and Asynchronous Web proxies and servers. Using this new feature, the container thread won’t lock when a request is suspended. And when it’s resumed, the request will be redispatched.

The ServletRequest interface gets new methods to that purpose:
- suspend()
- suspend(long timeout)
- resume()
- complete()

And it gets a set of query methods (or getters):
- isSuspended()
- isResumed()
- isTimeout()
- isInitial()

ServletResponse gets new methods as well:
- disable()
- enable()
- isDisabled()

ServletRequestListener as well:
- requestSuspended()
- requestResumed()
- requestCompleted()

Security Enhancements

The new spec defines support for programmatic login and logout. This is still in work-in-progress mode however Mordani gave us a sneak preview:

New methods for HttpServletRequest and HttpSession:
HttpServletRequest:
- login()
- logout()

HttpSession:
- logout()

HTTP-Only Cookie Support

There’s also HTTP-only cookie support. This type of cookie comes with a new attribute which prevents them from being accessed through client-side scripting. Therefore, HTTP-only cookies offer a good solution to mitigate XSS (Cross-Site Scripting) attacks. As far as I know, this is a Microsoft extension but the major browsers support it. To support it, new methods are added to Cookie class to check whether it’s HTTP-only or not:

- setHttpOnly()
- isHttpOnly()

Misc

The new spec includes:
- Enablement of REST JSR and JSF 2.0 JSR
- A standard mechanism to configure session tracking cookies.
- File upload, progress listener, where to store interim and final file.
- Container-wide initialization parameters
- ServletContextListener ordering
- Better welcome file support

Non-Servlet Enhancements

There is also a non-servlet enhancement: Ability to host EJBs in WAR files.

The Java Servlet 3.0 Specification is currently in early draft status. It’s planned to go public this summer (2008). Final version will be aligned with Java EE 6. Open-source implementations will be available through Apache Tomcat, Jetty and GlassFish.

- Yagiz Erkan -

JavaOne 2008: Java + You
JavaOne 2008: Opening General Session
JavaOne 2008: Java SE 6, Java SE 7, SOA, SCA and Performance
JavaOne 2008: SOA and Performance
JavaOne 2008: SOA, SCA, REST and Comet Discussed
JavaOne 2008: Comet (AJAX, Grizzly and Cometd)
JavaOne 2008: Top 10 Patterns of Scalability

Technorati Tags: Servlet, Java EE 6, Java SE 5, annotation, Asynchronous Servlet, XSS, Tomcat, Jetty, GlassFish