 |
Servlet 3.0 (JSR 315) update
Posted by mode on April 30, 2008 at 04:50 PM | Comments (11)
Update: The early draft of the specification is now available at the JCP site. Click here to get to the draft.
It's been a while since I put a post on the blog so I thought I would take this opportunity to give an update on the servlet 3.0 specification. The expert group has been working through to enhance the APIs in the servlet specification. This blog is to give an update to the developers about the features that are proposed for the upcoming early draft of the specification.
The main areas covered so far by the expert group are
- Pluggability and extensibility
- Ease of development
- Async support
- Security enhancements
- Some enhancements to the existing APIs.
Pluggability and extensibility
In keeping with one of the main theme for Java EE 6, the goal of this requirement is provide more extension points in the servlet container to allow developers to easily use frameworks / libraries by "just dropping" a jar file in the application classpath and not require any additional configuration in the application. Today, in a servlet container the application has one monolithic web.xml that defines all the deployment artifacts for the application, including the dependencies of the application on the framework components. In it's current state, a developer must go through the documentation of each framework that it depends on and declare the appropriate servlets, filters, Listeners, etc. To overcome this issue in servlet 3.0 we are adding a new feature that allows having more than one web.xml, or as it is being referred in the specification as web fragments. A framework can define it's own web.xml that declares the necessary components for the framework that is then included for use in the web applicaton. It is the job of the container to assemble all the fragments at deployment / runtime of the application.
Along with the changes mentioned above there are few new APIs to also allow programmatic addition of Servlets and Filters at start up time of an application.
API changes for configuration addition:
ServletContext: addServlet, addServletMapping, addFilter, addFilterMapping
Ease of Development
In servlet 3.0 one of the areas of focus is ease of development. The servlet 3.0 API is making use of annotations to enable a declarative style of programming for components of a web application. For example - to define a servlet you would use the following piece of code -
package samples;
import javax.servlet.http.annotation.*;
@Servlet(urlMappings={"/foo"})
public class SimpleSample {
}
The use of annotations makes web.xml optional and a developer does not really need to use it unless they want to change some configuration without changing code - for example at deployment time. Also, as with all the other parts of the Java EE platform, the descriptor always overrides the metadata provided via use of annotations.
Async support
The initial proposal for Async servlet support came from Greg Wilkins from Webtide and has been discussed and refined in the expert group. Support for async servlets allows you to suspend and resume request processing and enable and disable the response depending on the need of the application. A good use case of this servlet is in writing comet style applications. API changes for async support:
ServletRequest:
suspend, resume, complete, isSuspended, isResumed, isTimeout, isInitial
ServletResponse:
disable, enable, isDisabled
ServletRequestListener:
requestSuspended, requestResumed, requestCompleted
Security enhancements
While this is not in the early draft of the specification as it needs some more discussion in the expert group, I thought I would give a sneak preview of what might be in the next draft of the specification. Ron Monzillo from Sun who is a security expert and has done work on many of the security related JSRs proposed the addition of methods to HttpServletRequest and HttpSession to support programmatic login and logout. API changes for login / logout support:
HttpServletRequest: login, logout
HttpSession:logout
Enhancements to existing APIs
A few areas of the current API have been enhanced that will help in developer productivity. Listed below are some of them -
- Ability to get a ServletContext and a Response object from the Request object. To get a Context (to maybe get context information or to get a RequestDispatcher for example) today you need to create a HttpSession object just to get a reference to a Context object. With the addition of the new APIs you can now get the Context and the associated Response from the ServletRequest. API changes for getting a Context and Response:
ServletRequest:
getServletContext, getServletResponse
- Mark a cookie as an HttpOnly cookie. By setting a cookie to be an HttpOnly cookie you prevent client side scripting code from getting access to the cookie. Most modern browsers support this feature and it helps mitigate some kinds of cross-site scripting attacks. API changes to support HttpOnlyCookie:
Cookie:
setHttpOnly, isHttpOnly
Note: For details about all the API changes look at the javadocs (once the spec is available from the jcp website). The exact method signatures aren't duplicated here. Instead just the names are here to give an idea of the kind of changes.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
I wish you would get rid of the "up to the application server vendor" parts of security, so one would truly be able to move freely one application from one server to another. (userroles mappings for example)
Oh, and dynamic security settings, instead of harcoded paths in descriptors and mixing security calls in the business logic.
Cheers to Ron for proposing also the long forgotten logout feature ;-).
S!
Posted by: greeneyed on May 01, 2008 at 10:44 AM
-
Hi,
I hope annotation-based configuration doesn't imply a time-consuming scan of all classes in the classpath at every startup in order to discover the servlets!
How will the proposed "logout" feature work with HTTP authentication, which doesn't really have any logout mechanism?
- Chris
Posted by: chris_e_brown on May 02, 2008 at 12:48 AM
-
I think that the programmatic configuration option is a long needed feature. Reconfiguration *after* startup would be even better, but it's a start.
But the annotation fever bothers me a little... will every annotated class in the classpath be loaded and exposed? Even the ones in jars? Isn't it sort of a security issue?
I like annotations when used well, but I feel it has been abused lately... it seems that every aspect of every new spec must include configuration by annotations. I don't know, it just don't feel right...
Posted by: ronaldtm on May 02, 2008 at 06:11 PM
-
greeneyed: We will look into what can be done for security enhancements. We are starting to take the steps towards making security enhancements in the servlet specification.
- Rajiv
Posted by: mode on May 13, 2008 at 11:53 AM
-
Chris: We have gone through this discussion during Java EE 5 and we noticed that the benefits to developer far out weighs the minimal delay that it takes for deploying the app. Also if you absolutely care about performance you can turn off scanning for annotations and just continue using the deployment descriptor (web.xml) to specify all the metadata..
Posted by: mode on May 13, 2008 at 11:57 AM
-
Ronaldtm: For this release we are limiting it to adding configuration at startup time only. Reconfiguration has a whole set of issues which I would rather punt on for now and revisit it in a subsequent release. As for annotations - you need to define a url-mapping for every servlet / filter that you want to make available. There is a way to turn off automatic scanning and exposing the servlets if you choose to do so. We didn't see it to be a problem with Web Services (which run on top of the servlet container) if you use the annotaitons in the right way.
Posted by: mode on May 13, 2008 at 12:00 PM
-
Chris: Your point about annotation processing slowing down start up of web app is not an issue, because most of the application servers process annotations only once, i.e., during deployment of the application. e.g., GlassFish generates corresponding XML deployment descriptors out of annotations during deployment. During subsequent start up of application or application server, it just reads the information from XML DD.
Thanks,
Sahoo
Posted by: ss141213 on May 15, 2008 at 12:48 AM
-
Rajiv,
can you please clarify what you meant by "application classpath" when you said to allow developers to easily use frameworks / libraries by "just dropping" a jar file in the application classpath. Can the web.xml containing web-fragment be placed anywhere in the classloader space of the web app and be available to the web app?
Sahoo
Posted by: ss141213 on May 15, 2008 at 12:53 AM
-
Sahoo: Processing annotations only once is not a requirement of the specification. It can in fact use them even at runtime. We do that in JAX-WS in some cases for example. Generating the corresponding xml descriptor is one way of doing it in the implementation.
Posted by: mode on May 15, 2008 at 03:24 PM
-
Sahoo: The specification says that all the libraries in WEB-INF/lib and WEB-INF/classes must be looked into. Beyond that it is up to the implementation.
Posted by: mode on May 15, 2008 at 03:25 PM
-
mode:
I know generating equivalent DD from annotations at deployment time is not mandated by the spec. I mentioned about that alternative only to counter the argument that annotation processing can slow things down. The implementations that care too much about speed can choose an alternative like that.
Posted by: ss141213 on May 15, 2008 at 07:46 PM
|
java.net RSS Feeds
