Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Jetty/Feature/JNDI
Contents
- 1 Introduction
- 2 Feature
- 3 Setup
- 3.1 Deployment-time configuration
- 3.2 Classpath jars
- 3.3 What can be bound and general overview
- 3.4 Configuring env-entrys
- 3.5 Configuring resource-refs and resource-env-refs
- 3.6 Configuring DataSources
- 3.7 Configuring JMS Queues, Topics and ConnectionFactories
- 3.8 Configuring Mail
- 3.9 Configuring XA Transactions
- 3.10 Configuring Links
- 3.11 Global or scoped to a webapp
- 4 Demo Web Application
- 5 Additional Resources
Introduction
Jetty supports java:comp/env
lookups in webapps. This is an optional feature, and as such some setup needs to be done. However, if you're using the [Hightide] distribution of jetty, then this feature is already fully enabled for you, so you can skip any setup steps, and read the section on how to put objects into jetty's JNDI so that you can retrieve them at runtime.
Feature
Setup
Deployment-time configuration
Skip this step if you are using the Hightide distribution of jetty as JNDI is automatically enabled for you. For non-Hightide distributions, you may enable JNDI either for a particular web app or you can enable it by default for all webapps. In either case, we need to re-define the list of configurations that can be applied to a WebAppContext on deployment:
<Array id="plusConfig" type="java.lang.String"> <Item>org.eclipse.jetty.webapp.WebInfConfiguration</Item> <Item>org.eclipse.jetty.webapp.WebXmlConfiguration</Item> <Item>org.eclipse.jetty.webapp.MetaInfConfiguration</Item> <Item>org.eclipse.jetty.webapp.FragmentConfiguration</Item> <Item>org.eclipse.jetty.plus.webapp.EnvConfiguration</Item> <!-- add --> <Item>org.eclipse.jetty.plus.webapp.Configuration</Item> <!-- add --> <Item>org.eclipse.jetty.webapp.JettyWebXmlConfiguration</Item> <Item>org.eclipse.jetty.webapp.TagLibConfiguration</Item> </Array>
Now, to apply this to a single webapp, we create a context xml file that describes the setup of that particular webapp and instruct it to apply these special configurations on deployment:
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> <Array id="plusConfig" type="java.lang.String"> <Item>org.eclipse.jetty.webapp.WebInfConfiguration</Item> <Item>org.eclipse.jetty.webapp.WebXmlConfiguration</Item> <Item>org.eclipse.jetty.webapp.MetaInfConfiguration</Item> <Item>org.eclipse.jetty.webapp.FragmentConfiguration</Item> <Item>org.eclipse.jetty.plus.webapp.EnvConfiguration</Item> <!-- add for JNDI --> <Item>org.eclipse.jetty.plus.webapp.Configuration</Item> <!-- add for JNDI --> <Item>org.eclipse.jetty.webapp.JettyWebXmlConfiguration</Item> <Item>org.eclipse.jetty.webapp.TagLibConfiguration</Item> </Array> <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/my-cool-webapp</Set> <Set name="configurationClasses"><Ref id="plusConfig"/></Set> </Configure>
Alternatively, we could apply these configurations to every webapp that is deployed. To do that, we edit the $JETTY_HOME/etc/jetty.xml
file (or create a new new file and put it on the runline or put it in start.ini
) to add:
<Configure id="Server" class="org.eclipse.jetty.server.Server"> <Call name="setAttribute"> <Arg>org.eclipse.jetty.webapp.configuration</Arg> <Arg> <Array type="java.lang.String"> <Item>org.eclipse.jetty.webapp.WebInfConfiguration</Item> <Item>org.eclipse.jetty.webapp.WebXmlConfiguration</Item> <Item>org.eclipse.jetty.webapp.MetaInfConfiguration</Item> <Item>org.eclipse.jetty.webapp.FragmentConfiguration</Item> <Item>org.eclipse.jetty.plus.webapp.EnvConfiguration</Item> <Item>org.eclipse.jetty.plus.webapp.Configuration</Item> <Item>org.eclipse.jetty.webapp.JettyWebXmlConfiguration</Item> <Item>org.eclipse.jetty.webapp.TagLibConfiguration</Item> </Array> </Arg> </Call> </Configure>
Classpath jars
Now that we have the JNDI configuration for the webapp(s) set up, we need to ensure that the JNDI implementation jars are on jetty's classpath. These jars are optional, so won't be there by default. We add these into the classpath by using startup time OPTIONS:
java -jar start.jar OPTIONS=plus
You may now configure 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:
<env-entry/> <resource-ref/> <resource-env-ref/>
#Configuring env-entrys shows you how to set up overrides for <env-entry>
elements in web.xml. #Configuring resource-refs and resource-env-refs discusses how to configure support resources such as javax.sql.DataSource
.
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 XA Transactions.
You can define your naming resources with 3 scopes:
- jvm scope - the name is unique within the jvm
- server scope - the name is unique to the Server instance
- webapp scope - the name is unique to the WebAppContext instance
The section #Global or scoped to a webapp explains what scoping is, and shows you how to use it. Essentially, scoping ensures that JNDI bindings from one webapp do not interfere with the JNDI bindings of another - unless of course you wish them to.
Before we go any further, lets take a look at what kind of things can be bound into JNDI with Jetty.
What can be bound and general overview
There are 4 types of objects that can be bound into Jetty's JNDI:
- an ordinary POJO instance
- a java.naming.Reference instance
- an object instance that implements the java.naming.Referenceable interface
- a linkage between a name as referenced in web.xml and as referenced in the environment
The binding for all of these object types generally follows the same pattern:
<New class=type of naming entry> <Arg>scope</Arg> <Arg>name to bind as</Arg> <Arg>the object to bind</Arg> </New>
The type of naming entry
can be:
-
"org.eclipse.jetty.plus.jndi.EnvEntry"
for <env-entry>s -
"org.eclipse.jetty.plus.jndi.Resource"
for all other type of resources -
"org.eclipse.jetty.plus.jndi.Transaction"
for a JTA manager. We'll take a closer look at this in the #Configuring XA Transactions section. -
"org.eclipse.jetty.plus.jndi.Link"
for link between a web.xml resource name and a NamingEntry. See Configuring Links section for more info.
There are 3 places in which you can define naming entries:
-
jetty.xml
-
WEB-INF/jetty-env.xml
- context xml file
Naming entries defined in a jetty.xml
file will generally be scoped at either the jvm level or the Server level. Naming entries in a jetty-env.xml
file will generally be scoped to the webapp in which the file resides, although you are able to enter jvm or Server scopes if you wish, that is not really recommended. In most cases you will define all naming entries that you want visible to a particular Server instance, or to the jvm as a whole in a jetty.xml file. Entries in a context xml file will generally be scoped at the level of the webapp to which it applies, although once again, you can supply a less strict scoping level of Server or JVM if you want.
Configuring 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 convenient to be coded into a web.xml <env-entry>
. In this case, you can use org.eclipse.jetty.plus.naming.EnvEntry
and even configure them to override an entry of the same name in web.xml.
<New class="org.eclipse.jetty.plus.jndi.EnvEntry"> <Arg></Arg> <Arg>mySpecialValue</Arg> <Arg type="java.lang.Integer">4000</Arg> <Arg type="boolean">true</Arg> </New>
This example will define a virtual <env-entry>
called mySpecialValue
with value 4000
that is unique within the whole jvm. It will be put into JNDI at java:comp/env/mySpecialValue
for _every_ webapp deployed. 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
.
See #Global or scoped to a webapp for more information on other scopes.
Note that the Servlet Specification only allows the following types of object to be bound to an env-entry
:
- java.lang.String
- java.lang.Integer
- java.lang.Float
- java.lang.Double
- java.lang.Long
- java.lang.Short
- java.lang.Character
- java.lang.Byte
- java.lang.Boolean
However, Jetty is a little more flexible and will also allow you to bind custom POJOs, javax.naming.Reference's and javax.naming.Referenceable's. Be aware if you take advantage of this feature that your web application will *not be portable*.
To use the EnvEntry
configured above, use code in your servlet/filter/etc such as:
import javax.naming.InitialContext; InitialContext ic = new InitialContext(); Integer mySpecialValue = (Integer)ic.lookup("java:comp/env/mySpecialValue");
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 using the org.eclipse.jetty.plus.jndi.Resource
type of naming entry. You provide the scope, the name of the object (relative to java:comp/env
) and a POJO instance or a javax.naming.Reference instance or javax.naming.Referenceable instance.
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 | ||
javax.sql.DataSource | jdbc/myDB | java:comp/env/jdbc/myDB | ||
javax.jms.QueueConnectionFactory | jms/myQueue | java:comp/env/jms/myQueue | ||
javax.mail.Session | mail/myMailService | java:comp/env/mail/myMailService |
Configuring DataSources
Lets look at an example of configuring a javax.sql.DataSource. Jetty can use any DataSource implementation available on it's classpath. In our example, we'll use a DataSource from the Derby relational database, but you can use any implementation of a javax.sql.DataSource
. In this example, we'll configure it as scoped to a webapp with the id of 'wac':
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> ... <New id="myds" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id="wac"/></Arg> <Arg>jdbc/myds</Arg> <Arg> <New class="org.apache.derby.jdbc.EmbeddedDataSource"> <Set name="DatabaseName">test</Set> <Set name="createDatabase">create</Set> </New> </Arg> </New> </Configure>
The above would create an instance of org.apache.derby.jdbc.EmbeddedDataSource
, call the two setter methods setDatabaseName("test");
and setCreateDatabase("create");
and bind it into the JNDI scope for the webapp. If you have the appropriate <resource-ref> setup in your web.xml, then it will be available from application lookups as java:comp/env/jdbc/myds
.
To lookup your DataSource in your servlet/filter/etc do:
import javax.naming.InitialContext; import javax.sql.DataSource; InitialContext ic = new InitialContext(); DataSource myDS = (DataSource)ic.lookup("java:comp/env/jdbc/myds");
Configuring JMS Queues, Topics and ConnectionFactories
Jetty is able to bind any implementation of the JMS destinations and connection factories. You just need to ensure the implementation jars are available on Jetty's classpath.
Here's an example of binding an ActiveMQ in-JVM connection factory:
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> ... <New id="cf" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id='wac'/></Arg> <Arg>jms/connectionFactory</Arg> <Arg> <New class="org.apache.activemq.ActiveMQConnectionFactory"> <Arg>vm://localhost?broker.persistent=false</Arg> </New> </Arg> </New> </Configure>
There is more information about ActiveMQ and Jetty Integrating with ActiveMQ.
Configuring Mail
Jetty also provides infrastructure for providing access to javax.mail.Sessions from within an application:
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> ... <New id="mail" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id="wac"/></Arg> <Arg>mail/Session</Arg> <Arg> <New class="org.eclipse.jetty.jndi.factories.MailSessionReference"> <Set name="user">fred</Set> <Set name="password">OBF:1xmk1w261z0f1w1c1xmq</Set> <Set name="properties"> <New class="java.util.Properties"> <Put name="mail.smtp.host">XXX</Put> <Put name="mail.from">me@me</Put> <Put name="mail.debug">true</Put> </New> </Set> </New> </Arg> </New> </Configure>
The setup above creates an instance of the org.eclipse.jetty.jndi.factories.MailSessionReference
class, calls it's setter methods setUser("fred");
, setPassword("OBF:1xmk1w261z0f1w1c1xmq");
to set up the authentication for the mail system, then populates a set of Properties, setting them on the MailSessionReference instance. The result of this is that an application can lookup java:comp/env/mail/Session
at runtime and obtain access to a javax.mail.Session
that has the necessary configuration to permit it to send email via SMTP.
{tip} You can set the password to be plain text, or use Jetty's password obfuscation mechanism to make the config file more secure from prying eyes. Note that the other Jetty encryption mechanisms of MD5 and Crypt cannot be used as the original password cannot be recovered, which is necessary for the mail system. {tip}
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 XA 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 org.eclipse.jetty.plus.jndi.Transaction
object in a jetty config file. In the following example, we will configure the Atomikos transaction manager:
<New id="tx" class="org.eclipse.jetty.plus.jndi.Transaction"> <Arg> <New class="com.atomikos.icatch.jta.J2eeUserTransaction"/> </Arg> </New>
See also the instructions for how to configure JOTM. Contributions of instructions for other transaction managers are welcome.
Configuring Links
Usually, the name you configure for your NamingEntry should be the same as the name you refer to it as in you web.xml. For example:
In a context xml file: <Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> ... <New id="myds" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id="wac"/></Arg> <Arg>jdbc/mydatasource</Arg> <Arg> <New class="org.apache.derby.jdbc.EmbeddedDataSource"> <Set name="DatabaseName">test</Set> <Set name="createDatabase">create</Set> </New> </Arg> </New> </Configure>
and in web.xml:
<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.JNDITest</injection-target-class> <injection-target-name>myDatasource</injection-target-name> </injection-target> </resource-ref>
If you wish, you can refer to it in web.xml by a different name, and link it to the name in your org.eclipse.jetty.plus.jndi.Resource by using an org.eclipse.jetty.plus.jndi.Link type of NamingEntry. For the example above, we could refer to the jdbc/mydatasource
resource as jdbc/mydatasource1
by doing:
In a context xml file:
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> ... <New id="myds" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id="wac"/></Arg> <Arg>jdbc/mydatasource</Arg> <Arg> <New class="org.apache.derby.jdbc.EmbeddedDataSource"> <Set name="DatabaseName">test</Set> <Set name="createDatabase">create</Set> </New> </Arg> </New> </Configure> in a jetty-env.xml file: <source lang="xml"> <New id="map1" class="org.eclipse.jetty.plus.jndi.Link"> <Arg><Ref id='wac'/></Arg> <Arg>jdbc/mydatasource1</Arg> <!-- name in web.xml --> <Arg>jdbc/mydatasource</Arg> <!-- name in container environment --> </New>
and in web.xml:
<resource-ref> <res-ref-name>jdbc/mydatasource1</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <injection-target> <injection-target-class>com.acme.JNDITest</injection-target-class> <injection-target-name>myDatasource</injection-target-name> </injection-target> </resource-ref>
This can be useful when you cannot change web.xml but need to link it to a resource in your deployment environment.
Global or scoped to a webapp
As we said before, you can control the visibility of your JNDI naming entries within your jvm, Server and WebAppContext instances. Naming entries at the _jvm scope_ are visible by any application code, and are available to be bound to java:comp/env
. Naming entries at the _Server scope_ will not interfere with entries of the same name in a different Server instance, and are avilable to be bound to java:comp/env of any webapps deployed to that Server instance. Finally, the most specific scope are entries at the _webapp scope_. These are only available to be bound to java:comp/env of the webapp in which it is defined.
The scope is controlled by the 1st parameter to the NamingEntry.
The jvm scope is represented by a null parameter:
<New id="cf" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg></Arg> <Arg>jms/connectionFactory</Arg> <Arg> <New class="org.apache.activemq.ActiveMQConnectionFactory"> <Arg>vm://localhost?broker.persistent=false</Arg> </New> </Arg> </New>
The Server scope is represented by referencing the related Server object:
<Configure id="Server" class="org.eclipse.jetty.Server"> ... <New id="cf" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id="Server"/></Arg> <Arg>jms/connectionFactory</Arg> <Arg> <New class="org.apache.activemq.ActiveMQConnectionFactory"> <Arg>vm://localhost?broker.persistent=false</Arg> </New> </Arg> </New> </Configure>
The webapp scope is represented by referencing the related WebAppContext object:
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext"> ... <New id="cf" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg><Ref id='wac'/></Arg> <Arg>jms/connectionFactory</Arg> <Arg> <New class="org.apache.activemq.ActiveMQConnectionFactory"> <Arg>vm://localhost?broker.persistent=false</Arg> </New> </Arg> </New> </Configure>
As you can see, the most natural config files in which to declare naming entries of each scope are:
-
etc/jetty.xml
- jvm or Server scope -
WEB-INF/jetty-env.xml
or a context xml file - webapp scope
Demo Web Application
There is a demonstration webapp 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 the transaction manager of your choice and Derby . At the time of writing, the webapp has been tested with both JOTM and with Atomikos transaction managers.
Building the Demo
The demo webapp is included with Jetty Hightide distribution. Alternatively, it can be built from sources located in examples/test-jndi-webapp
. There is a README.txt
file in there which explains how to build it, and how to add support for different transaction managers.
- run
mvn clean install
to build it - then edit
contexts/test-jndi.xml
and uncomment one of the transaction manager setups - then edit
contexts/test-jndi.d/WEB-INF/jetty-env.xml
and uncomment one of the transaction manager setups - copy a
derby.jar
to the jettylib/
directory, as well as copy all the necessary jars for the flavour of transaction manager you are using. There are instructions for some of the popular transaction managers on the wiki at JNDI
You run the demo like so:
java -jar start.jar OPTIONS=plus
The URL for the demonstration is at:
http://localhost:8080/test-jndi
Adding Support for a Different Transaction Manager
- Edit the
src/etc/templates/filter.properties
file and add a new set of token and replacement strings following the pattern established for ATOMIKOS and JOTM. - Edit the
src/etc/templates/jetty-env.xml
file and add configuration for new transaction manager following the pattern established for the other transaction managers. - Edit the
src/etc/templates/jetty-test-jndi.xml
file and add configuration for the new transaction manager following the pattern established for the other transaction managers.
Additional Resources
For more information on setting up a JNDI datasource please see How to Configure JNDI Datasource page.
For documentation on how to configure jetty-env.xml, please consult the reference guide.