Tomcat context management

8
votes

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?

2
javatomcat
How are you deploying to Tomcat? Manually or using an IDE (Eclipse) plugin? – BalusC
Manually. I create the war file and move it to webapp directory. – Hemang
Do you have the autoDeploy attribute set on the host element in server.xml? Try setting that to false. – matt
See this recent thread on SF with the same problem serverfault.com/q/192784/37747 and on SO stackoverflow.com/questions/4032773/…. I've now gone full circle with these references and crosslinks :) – JoseK
Usually I delete the old folder and redeploy the WAR field because of the /META-INF/context.xml wackyness. – Michael Shopsin

2 Answers

2
votes

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.

1
votes

If you want to avoid overwriting of 'context.xml', you could go to Tomcat Manager url and then uninstall the previous app and install the new war/ear. This way you have more control on the installation process.