An Introspection of the JSR 135 Specification

Servlets in Brief

A Servlet is a Java technology that allows a container to generate dynamic content. These containers are called servlet containers. Tomcat is one good example of such a servlet container. The basic Servlet interface defines a service() method to handle client requests. The web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads. A servlet will also have a variety of methods like doGet, doPost, doPut, doDelete and doHead which is a specialized version of doGet returning only a header. The use of a SingleThreadModel interface will guarantee that only a single thread will execute in a given servlet’s service method.

Most Java web frameworks build on the Servlet API and require configuration of Servlets, Filters and Listeners. The JSR 315 will be a part of Java EE 6

Some of the proposed changes

1. Support for continuations. The general idea of continuations is that you can save the current state of an object and return back to the saved state at a later point of time in your execution lifecycle. It is almost like taking a hiatus from your hectic work schedule, going on a trip around the world and coming back to find that everythingis as you left, no catching up, no making up work, just consitnue on as you were before your hiatus, how cool would that be. This is a concept that was popularized by Scheme and also is a major part of Jetty as Jetty Continuations. Now with JSR 135, the request object will now have a suspend() and resume() to suspend and resume execution from a later thread.
2. Plugability - Today all deployment artifacts are defined in web.xml, which can at times just become large and unmanageable. So multiple frameworks can lead to having us define all the servlet mappings in this web.xml file. But imagine if each framework coems withit’s own web.xml that defines only the components that framework needs, and if we leave the job of assembling the components together to the container, our task would be so much easier, and our project would be so much easier to maintain. This spec introduces web fragements that does exactly this task. In addition to this kind of plug ability the new JSR also provides a feature where servlets can be inserted into the container dynamically at runtime using the servletContext.addServlet() and servletContext.addServletMapping(). One drawback of this feature is that there could be potential security risks since JARS can register their own servlets.
3. Annotations - I am sure many of you are familiar with annotations, a technique to try to eliminate configuration files by introducing the configuration details in the source code file. JSR 135 introduces POJOS for servlets, so no more extending from HttpServlet. Just use the annotation @Servlet(urlmapping = {’mapping‘}, name=“abc” } and then use @GET, @POST, @PUT, @DELETE, @HEAD. Servlet Filters are defined using @ServletFilter and @FilterMapping. Unfortunately this Annotations methodology is not as hunky dory and cool as it looks, there are lots of potential problems that Roy van Rijn has mentioned on his post on theserverside.com which include potential issues with having two methods with the same annotations like @GET, there are no IDEs that are setup to detect Servlet using annotations. Also with annotations what we lose is that previously we could just override the methods, now you cannot do that.
4. Programmatic entry - Potentially there might be support for programmatic login and logout as part of the HttpServletRequest and HttpSession.
5. HttpOnly Cookies - Ability to prevent client side scripting code from getting access to cookies by defining HttpOnly cookies.

References:
http://www.theserverside.com/tt/articles/articles.tss?l=PonderingAboutJSR135
http://weblogs.java.net/blog/mode/archive/2008/04/servlet_30_jsr_1.html

Tags: jsr 135, servlet