Rajiv Mordani's Blog

Rajiv Mordani is a senior engineer at Sun Microsystems, working on the web technologies as an architect. Rajiv has been involved in the open source community at Apache with xerces and tomcat in the past doing implementation and also as the JAXP specification lead. He is currently the specification lead for Servlets.

Aggregrated feed for GlasFish webtier related blogs

Forum and mailing list dedicated for webtier in GlassFish

JSR 315 Needs YOU: Response to Greg's blog

Greg Wilkins from Webtide blogged about the pluggability mechanism and raised an issue with the auto-scanning. Hopefully this blog will make the argument for the simple scanning of annotations and web-fragments and argue against the case of having a more flexible scheme in this release of the servlet specification.

I will start with the annotation case first and then talk about the web-fragments. When you use annotations to declare servlets and Filters then you must have a url-mapping / FilterMapping attribute on the corresponding servlet / Filter. In this way there is no convention by which a servlet is exposed without having an explicit mapping. Also , as with the rest of the Java EE platform, specifically technologies like EJB and Web Services, the deployment descriptor is used to override information that is specified via annotations. So if you have a servlet that is declared via annotations during development and now you need to change one attribute of the servlet when you go from development to production, you don't need to modify the code. Instead you override the configuration using the web.xml file. In the example below I show how this can be used -

@Servlet(url-mapping="/foo")
public class MyServlet {
    @GET
    public void handleGet(HttpServletRequest req, HttpServletResponse res) {
         ...
     }
}

<web-app>
  <servlet-mapping>
    <servlet-name>
      MyServlet
    </servlet-name>
    <url-pattern>
      /MyApp
    </url-pattern>
  </servlet-mapping>
</web-app>

If you didn't want any of the annotations to be processed at all by the container and wanted to specify all the configuration via the deployment descriptor, then, like with the rest of the Java EE 5 platform, we have the metadata-complete element in the descriptor. If the element is present and set to "true" then the container will not process any annotations and just use the configuration specified in the descriptor. This provides a way disable the auto-scanning for those that have concerns about performance, and security. This is consistent with what we have today in Java EE 5 platform and has worked well with EJBs and JAX-WS (Web Services APIs). We have not received any negative feedback about security and performance being an issue. Web Services are endpoints that are exposed on the web so the argument someone makes about there not being a security hole in EJB does not stand true for Web Services.

The second issue is about auto-scanning of web-fragments. The early draft of the specification says that the container needs to process web-fragments and make available the servlets, filters an listeners defined via the fragments. As discussed in my earlier post, this helps with use of frameworks. Currently the early draft of the specification says that the same flag - metadata-complete controls both the scanning of annotations and fragments. I still think that is sufficient for the developers. However during JavaOne we had an expert group face-to-face meeting and discussed the possibility of having another flag to control the scanning of web fragments and use the metadata-complete just to control scanning of annotations. Again similar to metadata-complete this flag would control whether to scan for web-fragments or not. If you choose not to scan the web-fragments then you would need to specify the entire metadata that you need in in the web.xml of the application, a-la metadata-complete :). For those that have major security concerns this would probably be the route to go because even if you do have the include mechanism there would be no way to specify just one servlet from the jar file. The container would still scan for all the servlets, filters and listeners from the framework available. The concept of "trusting" certain frameworks doesn't seem to solve the problem. Let's take Spring for example - if you choose Spring as the framework but didn't want one of the servlets defined in Spring to be available. The include mechanism would not work for you. You would have to fall back on defining everything in the web.xml of the application anyways. The benefit that the include proposal from Greg Wilkins is very little specially if the main concern is that servlets and filters are being exposed without the user intending to do so. I think that it is the problem of the framework developer and not the user of the framework to make sure that they don't expose certain types of components. By using a flag to control scanning you can effectively get what the include mechanism provides except you don't get partial scanning of only a certain set of jars. The include mechanism would probably only make the descriptor more verbose in having to list the jars you want scanned.

Another mechanism that came up during the face-to-face which hasn't been still talked about in the expert group is the concept of disabling servlets and filters in the application's web.xml. For example we could have in the application's web.xml the following -

  <servlet>
    <servlet-name>FrameworkServlet</servlet-name>
    <enabled>false</enabled>
  </servlet>

Servlet 3.0 pluggability

Pluggability

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. At deployment the container is responsible for discovering the web.xml fragments and processing them. A new element is being added to the schema for web applications - web-fragment that can define servlets, filters listeners. Below is a simple example of such a fragment.

<web-fragment>
  <servlet>
    <servlet-name>welcome</servlet-name>
    <servlet-class>
      WelcomeServlet
    </servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>welcome</servlet-name>
    <url-pattern>/Welcome</url-pattern>
  </servlet-mapping>
...
</web-fragment>

In addition to changes to modularize the web.xml there are also annotations being defined to declare servlets (@Servlet), filters (@ServletFilter) and the annotations have all the attributes defined to make web.xml optional. These attributes contain information like url-mapping, init-params and other information that would typically be defined in the deployment descriptor. This way Servlets, filters etc can be defined entirely using annotations and would be picked up from the WEB-INF/classes or WEB-INF/lib directory.

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 adding configuration are added to the ServletContext class and are listed here below:

ServletContext: 
    addServlet 
    addServletMapping 
    addFilter 
    addFilterMapping 

@ServletContextListener
public class MyListener {
    public void contextInitialized (ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        sc.addServlet("myServlet", 
                      "Sample servlet", 
                      "foo.bar.MyServlet", 
                       null, -1);
        sc.addServletMapping("myServlet", 
                             new String[] {"/urlpattern/*"});
    }
}

@ServletContextListener
public class MyListener {
    public void contextInitialized (ServletContextEvent sce) {
        ServletContext sc = sce.getServletContext();
        sc.addFilter("myFilter", 
                     "Sample Filter", 
                     "foo.bar.MyFilter", 
                      null);
        sc.addFilterMapping("myFilter", 
                             new String[] {"/urlpattern/*"},                         
                            “myServlet”,
                             DispatcherType.REQUEST, false);
    }
}

As you can see with the changes above now the onus is on the framework authors to make sure that they declare and make available the components and be self sufficient. As for the developers / users of the frameworks they now just need to include these libraries in their application and start using it.

Servlet 3.0 (JSR 315) update

• Pluggability and extensibility
• Ease of development
• Async support
• Security enhancements
• Some enhancements to the existing APIs.

Pluggability and extensibility

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

package samples;
import javax.servlet.http.annotation.*;
@Servlet(urlMappings={"/foo"})
public class SimpleSample {
}

Async support

Security enhancements

Enhancements to existing APIs

• 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.

June 2008

Search this blog:

Categories

Archives

May 2008
April 2008
October 2007
September 2007
July 2007
June 2007
May 2007
December 2006
July 2006
April 2006
June 2005

Recent Entries

Aggregrated feed for GlasFish webtier related blogs

Forum and mailing list dedicated for webtier in GlassFish

JSR 315 Needs YOU: Response to Greg's blog

This work is licensed under a Creative Commons License.