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:
anonymous wrote : 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?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005835#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...