0

In Tomcat, it looks like I must specify any JNDI resources in both the context.xml and my web.xml. Is this correct? Is there any way around this? I would think that one configuration in the context.xml would be sufficient. Here is the related documentation from the Tomcat User Guide.

Note that the resource name (here, bean/MyBeanFactory must match the value specified in the web application deployment descriptor.

Glassfish does not require configuration in this manner. In Glassfish, you configure the JNDI resources (like a JDBC connection pool) on the server, and the application code gains a reference to the resource though the JNDI lookup. There is no need to an extra entry in the web.xml file.

What I'm concerned abut is this: if Glassfish reject this duplicate JNDI configuration, but Tomcat requires it, then I suddenly need to support two web.xml files, depending on the environment the application will be deployed to. It simply seems more complicated and cumbersome than it needs to be.

Vinnie
  • 12,400
  • 15
  • 59
  • 80

2 Answers2

0

The context.xml file and web.xml are two ways to accomplish largely the same thing. The first in Tomcat-specific. The second is standard, defined by the Servlet specification and other Java EE-related specs.

For example, as described in the doc, you can use either of these to pass an initialization parameter to your web app:

  • <Context> <Parameter>… in the context.xml file
  • <context-param> <param-name>… in the web.xml file

Similarly, both can be used to define resources to be made available via JNDI. Both can be used to define listeners for lifecycle events.

See this Question for details: context.xml vs web.xml in web application

You do not need to use both. However, the Tomcat documentation recommends that if using context.xml you also repeat in web.xml. I do not understand that recommendation.

So why two ways?

  • The standard way useful because it is, well, standard. You can swap out Tomcat for another Servlet container without bothering to change your web.xml files.
  • The Tomcat-specific way is useful because it allows you to do more than you can do in the standard way. For example, this quote from the Tomcat 8.0.35 JNDI Resources HOW-TO:

Tomcat provides a number of Tomcat specific options for JNDI resources that cannot be specified in web.xml. These include closeMethod that enables faster cleaning-up of JNDI resources when a web application stops and singleton that controls whether or not a new instance of the resource is created for every JNDI lookup. To use these configuration options the resource must be specified in a web application's element or in the element of $CATALINA_BASE/conf/server.xml.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
0

Glassfish supports all elements of the web.xml DTD, and the resource-env-ref is one of those, so you shouldn't have to maintain multiple copies. Does Glassfish explicitly throw an error when you use it?

Femi
  • 64,273
  • 8
  • 118
  • 148
  • Not sure - still having difficulty is actually getting this to work correctly in Tomcat - then I'll retest against Glassfish. I still find it odd that Tomcat requires this extra config while Glassfish does not. – Vinnie Jun 28 '11 at 16:05
  • The extra config stuff is part of the spec: I guess glassfish opted to do without it. The tomcat default context is rooted at java:comp/env: not entirely sure you can do an absolute JNDI lookup in the style you want without changing your code. – Femi Jun 28 '11 at 16:34