The tomcat 6.0 document at http://tomcat.apache.org/tomcat-6.0-doc/config/context.html says:
Only if a context file does not exist for the application in the
$CATALINA_BASE/conf/[enginename]/[hostname]/
, in an individual file at/META-INF/context.xml
inside the application files. If the web application is packaged as a WAR then/META-INF/context.xml
will be copied to$CATALINA_BASE/conf/[enginename]/[hostname]/
and renamed to match the application's context path. Once this file exists, it will not be replaced if a new WAR with a newer/META-INF/context.xml
is placed in the host's appBase.
However I noticed that if you put new war file in webapp directory, the context.xml
in META-INF
directory replaces context.xml
in $CATALINA_BASE/conf/[enginename]/[hostname]
.
Is there any configuration which makes sure that context.xml
in $CATALINA_BASE/conf/[enginename]/[hostname]/
is not overwritten whenever new war file is deployed.
Edit: I am using autodeploy="true" From the comment of JoseK, I understand when tomcat sees new war file, it undeploys old application (leading to deletion of context file) and deploys the the new war file (leading to creation of new war file). In that case the above information from tomcat document is not relavant. The new question can there be any situation where the above thing can happen?
What is a Tomcat Context. In Tomcat, the Context Container represents a single web application running within a given instance of Tomcat. A web site is made up of one or more Contexts. For each explicitly configured web application, there should be one context element either in server.
The docBase attribute is a path to the WAR file or exploded deployment directory. It is relative to the webapps directory, although an absolute path can be used. The path attribute is the one we are most interested in, as it defines the context path of the application.
I agree that the documentation is misleading. Normally, this behaviour is actually welcomed since when you deploy a new version of your application, you want to have your updated context.xml file deployed as well. If you plan on editing your context.xml file manually on your production server, I suggest skip it altogether and copy its content to conf/server.xml file.
A quick patch/solution to your problem (wouldn't do it myself) is to mark the context.xml file as readonly after it has been deployed and updated the first time. This way Tomcat cannot delete/update it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With