Introduction

The Java Servlet 2.5 Specification added 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.

Feature

Set up

Annotation processing is not enabled by default by the standard jetty distribution, only by the jetty-hightide distribution. To enable annotation processing you will need to do some configuration file setup, and also add the OPTIONS for annotation to put the annotation-related jars onto the classpath.

The above is the basic set of configurations that need to be applied to a webapp upon deployment. You can apply these configurations to a specific webapp only, all webapps deployed by a particular deployer, or all webapps deployed into a server.

Tip:$JETTY_HOME/etc/jetty-plus.xml comes pre-setup with these configurations, and applies them to all webapps deployed into a Server instance. Edit start.ini to add jetty-plus.xml, and then add "annotations" to the list of OPTIONS and you're done.

Applying the configurations to a single webapp

If you elect not to use $JETTY_HOME/etc/jetty-plus.xml, and want to enable annotation processing for only a single webapp, you will need to create a context xml file for that webapp and put the configurations definition into it. Here's an example, which will set up annotation processing for the webapp in $JETTY_HOME/webapps/my-cool-webapp:

Now add "annotations" to the OPTIONS definition in start.ini to get the annotation-processing related jars onto jetty's runtime classpath and you're ready to run.

Applying the configurations to webapps deployed by a deployer

If you'd like to restrict the usage of annotations to only a subset of your webapps, you can copy them into a directory, and then set up a WebAppDeployer for them which will apply the configurations. For example, suppose you have moved the webapps into the directory $JETTY_HOME/plus-webapps, you can create a new xml configuration file (remembering to add it to start.ini, or edit an existing xml file), and add:

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:

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:

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.