Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Jetty Powered:
Contact the core Jetty developers at
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

Using JNDI Resources with jetty6



This feature is available as from jetty-6.0.0beta10.

Jetty6 supports java:comp/env lookups in webapps. This is an optional feature provided by the 2 jars lib/naming/jetty-naming.jar and lib/plus/jetty-plus.jar. As it is an optional feature, some setup needs to be done.

Firstly, to enable JNDI for a web application, you need to configure the WebAppContext to parse the web.xml file and perform the java:comp/env linkages. The class that does this is, and we specify its name in the list of configurations to be applied to the webapp when we define the org.mortbay.jetty.webapp.WebAppContext for it. The following example enables naming services for the xyzWebAppContext:

Or, more conveniently, you can specify that these configurations are used for every webapp deployed from a specified directory, eg webapps-plus. Assuming the same definition of the Configurations array as above, instead of explicitly configuring each individual webapp, you can say instead:

In either case, you may now configure container-wide naming resources that can be referenced in a web.xml file and accessed from within the java:comp/env naming environment of the webapp during execution. Specifically, you may configure support for the following web.xml elements:

Configuring resource-refs and resource-env-refs discusses how to configure support resources such as javax.sql.DataSource. You can also configure global env-entry elements that can override the env-entry settings in a web.xml file. See Configuring global env-entrys.

Furthermore, it is possible to plug a JTA javax.transaction.UserTransaction implementation into Jetty so that webapps can lookup java:comp/UserTransaction to obtain a distributed transaction manager. See Configuring Transactions.

Configuring global env-entrys

Sometimes it is useful to be able to pass configuration information to a webapp at runtime that either cannot be or is not convient to be coded into a web.xml env-entry. In this case, you can use in the jetty.xml file and configure them to override an entry of the same name in web.xml.

This example will define an env-entry called mySpecialValue with value 4000 that will be put into JNDI at java:comp/env/mySpecialValue for every webapp. Moreover, the boolean argument indicates that this value should override an env-entry of the same name in web.xml. If you don't want to override, then omit this argument or set it to false.

Configuring resource-refs and resource-env-refs

Any type of resource that you want to refer to in a web.xml file as a resource-ref or resource-env-ref can be configured in a jetty.xml file using the class. You need to provide the name of the object, relative to java:comp/env and the instance of the object itself. The J2EE Specification recommends that DataSources are stored in java:comp/env/jdbc, JMS connection factories under java:comp/env/jms, JavaMail connection factories under java:comp/env/mail and URL connection factories under java:comp/env/url. For example:

Resource Type

Name in jetty.xml

Environment Lookup










Lets look at an example of configuring a javax.sql.DataSource. In our example, we'll use a DataSource from the Atomikos transaction service:



If you want to try this yourself, you will need to download hsql, download Atomikos and install the console web application. There are instructions on how to do this in the section below.



When configuring Resources, you need to ensure that the type of object you configure matches the type of object you expect to lookup in java:comp/env. For database connection factories, this means that the object you register as a Resource must implement the javax.sql.DataSource interface.

We will be adding more examples of configuring database datasources (eg using XAPool and DBCP) and jms connection factories, so check back regularly. Contributions are also welcome.

Configuring Transactions

If you want to be able to perform distributed transactions with your resources, you will need a transaction manager that supports the JTA interfaces that you can lookup as java:comp/UserTransaction in your webapp. Jetty does not ship with one, rather you may plug in the one of your preference. You can configure the one of your choice using the object in jetty.xml. In the following example, we will configure the Atomikos transaction manager:



In order to use the Atomikos transaction manager, you will also need to install the Atomikos web console. You can copy and modify the following jetty.xml snippet:

Or, if you're using the etc/jetty-plus.xml configuration file, all webapps copied to webapps-plus/ will be automatically deployed so you won't need to explicitly configure the Atomikos console.

We will be adding more examples of configuring other transaction managers (such as JOTM), so check back regularly. Contributions are also welcome.

Demo Web Application

There is a demonstration webapp available in webapps-plus/test-jndi that is configured by etc/jetty-plus.xml, which sets up examples of all of the JNDI resources we've discussed so far.

In order to run this demonstration, you will need to download Atomikos and download Derby, which is an embeddable Java based relational database that supports XA transactions.

Copy the following Atomikos jars to lib:

  • transactions.jar
  • licenseJTA.jar
  • jta.jar

Copy the following Derby jars to lib:

  • derby.jar

To run all of the demos, including the JNDI demo:

The URL for the demonstration is:


  • No labels
Contact the core Jetty developers at
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery