Looking at this JIRA entry:
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:
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?