Difference between revisions of "Jetty/Feature/Annotations"

Revision as of 01:09, 9 June 2010

Introduction

The 2.5 Servlet Specification adds the ability to inject JNDI resources into fields and methods of servlets, filters and listeners, and also to perform certain callbacks at various points in the lifecycle of a web application.

JNDI resource injection and the lifecycle callbacks can be specified entirely within the web.xml file, or alternatively marked up as annotations in your source code. You can even use a combination of annotations and web.xml declarations.

One important thing to be aware of is that the 2.5 Servlet Specification introduced a new attribute into the <web-app> element, the metadata-complete attribute. If true, then the web container will NOT search the webapp for source code annotations, and your web.xml file must contain all resources required. If false or not specified, then jetty is required to examine all servlets, filters and listeners in the webapp for annotations. Therefore, you can save startup time by using this attribute correctly - if you don't want to use annotations then ensure you mark metadata-complete="true", otherwise you will pay the penalty of the code examination.

Here's an example of setting this attribute:

<web-app 
   xmlns="http://java.sun.com/xml/ns/j2ee" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" 
   metadata-complete="false"
   version="2.5">

Feature

Servlet 2.5 Annotations

• @Resource equivalent to resource-ref, resource-env-ref, env-entry and message-destination-ref in web.xml
• @Resources declares java:comp/env name linkages for reference by JNDI lookups
• @PostConstruct equivalent to post-construct in web.xml
• @PreDestroy equivalent to pre-destroy in web.xml
• @RunAs equivalent to run-as in web.xml

Resource Injections

Resource injections make available an object from JNDI as the value of a field or method parameter of a servlet, filter or listener class.

We'll look at a couple of small examples of how to declare them in web.xml and how to declare them in code, but for more in-depth information, you should consult the Common Annotations for the Java Platform Specification (JSR250), the Servlet 2.5 Specification (JSR154) and the JavaEE Specification v5 (JSR244).

Here is a small example of the injection of a DataSource resource via a web.xml declaration:

  <resource-ref>
    <res-ref-name>jdbc/mydatasource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    <injection-target>
      <injection-target-class>com.acme.MyServlet</injection-target-class>
      <injection-target-name>myDatasource</injection-target-name>
    </injection-target>
  </resource-ref>

This example shows that the resource named java:comp/env/jdbc/mydatasource will be injected by Jetty into the the field named myDatasource or the method named setMyDatasource(javax.sql.DataSource) in the instance of the class com.acme.MyServlet before it goes into service.

The equivalent injection using an annotation on the field instead would be:

import javax.sql.DataSource;
import javax.annotation.Resource;
import javax.servlet.http.HttpServlet;
 
public class MyServlet extends HttpServlet
{
    @Resource (name="jdbc/mydatasource", type=DataSource.class)
    private DataSource foo;
 
}

The equivalent as an annotation on the method would be:

import javax.sql.DataSource;
import javax.annotation.Resource;
import javax.servlet.http.HttpServlet;
 
public class MyServlet extends HttpServlet
{
    private DataSource foo;
 
    @Resource (name="jdbc/mydatasource", type=DataSource.class)
    private void setMyDatasource (DataSource ds)
    {
        foo = ds;
    }
 
}

Lifecycle callbacks: PostConstruct PreDestroy

The Servlet 2.5 Specification (JSR154) also introduces the concept of lifecycle callbacks. These are of two types: a post-construction callback, and a pre-destruction callback. The former will be invoked after all resource injections have been performed on an instance of a managed class (eg servlet, filter or listener) but before it goes into service. The latter is invoked just before the container removes the instance from service. Let's look at how you might declare these callbacks in a web.xml file:

<post-construct>
    <lifecycle-callback-class>com.acme.MyServlet</lifecycle-callback-class>
    <lifecycle-callback-method>myPostConstructMethod</lifecycle-callback-method>
</post-construct>
 
<pre-destroy>
    <lifecycle-callback-class>com.acme.MyServlet</lifecycle-callback-class>
    <lifecycle-callback-method>myPreDestroyMethod</lifecycle-callback-method>
</pre-destroy>

The above example would invoke the method myPostConstructMethod() on the instance of the class com.acme.MyServlet before the servlet is put into service, and would invoke the method myPreDestroyMethod() on the instance before it goes out of service.

Here's how the annotations would look instead:

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.servlet.http.HttpServlet;
 
public class MyServlet extends HttpServlet
{
    @PostConstruct
    private void myPostConstructMethod ()
    { 
        System.err.println("PostConstruct called");
    }
 
    @PreDestroy
    private void myPreDestroyMethod ()
    {
        System.err.println("PreDestroy called");
    }
}

Security

The @RunAs annotation is equivalent to the run-as element in web.xml: it is a role which is propagated as the security identity in calls to EJBs.

Here's an example of a web.xml declaration:

  <servlet>
    <servlet-name>MyServlet</servlet-name>
    <servlet-class>com.acme.MyServlet</servlet-class>
    <run-as>special</run-as>
  </servlet>

Here is the equivalent as an annotation:

import javax.annotation.security.RunAs;
import javax.servlet.http.HttpServlet;
 
@RunAs("special")
public class MyServlet extends HttpServlet 
{
}