<Environment> entry in Tomcat's context file

[brianr]

I'm reposting this, since the first post doesn't even display the Topic title correctly (the use of the greater-than and less-than symbols)....

I'm looking into the possibility of migrating our web applications from standalone Tomcat to JBoss AS. One difference I seem to have encountered arises from an error related to the lookup of values we had defined in entries in our web application contexts... when the WAR file is deployed in JBoss, our servlets can't seem to locate those entries.

The context files included something along the lines of:

<Environment name="importantList" value="1,2,3" type="java.lang.String />

Then, in a servlet that is loaded upon startup of the application, we read in this variable to initialize some important information in the web application that needs to be different between our development, QA, and production environments:

Context ctx = new InitialContext();
Context envCtx = (Context) ctx.lookup("java:comp/env");
String importantList = (String) envCtx.lookup("importantList");

How is something similar to this accomplished with JBoss? In which file would the variable need to be defined? I'd prefer to keep this outside of the WAR file, if possible, as we are able to do in standalone Tomcat. Doing so greatly simplifies our process of moving from Development to QA to Production, as we're able to simply copy the WAR file to the appropriate server as it is approved at each stage of testing, without changing any of the files internal to the WAR.

[brianr]

Looking at this JIRA entry:
http://jira.jboss.com/jira/browse/JBAS-2290

I see that despite JBoss's integration of Tomcat, it has chosen to discard a bit of real flexibility in how it handles context files. The JIRA case discusses the location of context.xml as though it's an either/or between META-INF and WEB-INF, quoting the Tomcat documentation for contexts found here:

http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

However, the Tomcat documentation clearly states that the five possible locations for a Context element:

1. Nested inside a Host element (in server.xml, etc)
2. In $CATALINA_HOME/conf/context.xml (context information shared by all webapps)
3. $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default (context information shared by all webapps)
4. $CATALINA_HOME/conf/[enginename]/[hostname]/myApp.xml (context information used only by the "myApp" web application)
5. Finally, if a Context element hasn't been found for a web application in any other location, Tomcat looks for the META-INF/context.xml file.

Scott Stark concludes the discussion in the above-mentioned JIRA case by stating that instead of looking in the META-INF directory, JBoss ought to look in the WEB-INF directory instead for the context information. That only addresses the fifth possible location for context files as far as Tomcat is concerned, though... are the other four possibilities ignored by JBoss?

In the JBoss WIKI related to contexts and other locations, great emphasis is placed on the philosophy that all application-specific settings should go in the WEB-INF directory, in either context.xml or web.xml. That's fine in many instances, perhaps, but especially when you look at the same Tomcat documentation for contexts and scroll down to the section on "Environment Entries", you'll see that while they fully support the ability to put those entries into the web.xml file, they understand the flexibility inherent in being able to place those entries into an external context file:

This is equivalent to the inclusion of the following element in the web application deployment descriptor (/WEB-INF/web.xml) ... but does not require modification of the deployment descriptor to customize this value.

The same flexibility is also found if you scroll further down the Tomcat documentation to view the section titled "Resource Definitions". There are deployment benefits to being able to define these in a location outside of the deployment descriptor, and outside of the WAR file for a web application, but still be specific to that web application. Case-in-point: the desire to send a single WAR file, without modification (that in itself may introduce new errors, typos, etc), through the chain of testing on a development server, followed by testing on a QA server, followed by deployment on a production server. Each of these server environments are likely to require different Resource definitions and Environment entries.

Has JBoss discarded Tomcat's flexibility in being able to externalize webapp-specific pieces of information? If so, why impose such limitations? And if not (which is my hope), then how are Environment entries and Resource definitions specified outside of a WAR file?