Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm developing a web-based Java application at work and (obviously) have to run it locally during development. I've figured out the Tomcat docs and have a suitable context.xml file in /etc/tomcat6/Catalina/localhost/ but every so often, Tomcat decides to delete it! Which means I have to put it back and restart Tomcat.

Why does it do this? I have searched the Tomcat docs about it and am none the wiser.

(Oh yes: it's not actually called context.xml but owners.xml as that's the HTTP path prefix for this application.)

Update

I've now seen Tomcat delete the file whilst Tomcat was running. I think I need to file a bug...

share|improve this question
add comment

7 Answers

up vote 4 down vote accepted

Quick summary: there are several conditions (like changing the war file, deleting the webapp or replacing it with new content) under which tomcat will undeploy the context including removing the context file.

Details: Whether tomcat does or doesn't do autoDeployment (means checking for changes in your .xml descriptor as well as checking changes in the webapp directory) is driven by:

  1. server.xml localted in $CATALINA_HOME/conf/server.xml section:

    <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

  2. You can also set this property in your context file overloading the value

Quoting the doc for cases when autoDeploy=true may cause removal of your context file:

  • Deleting a WAR file will trigger an undeploy of the application with the removal of any associated expanded directory, context file and work directory.
  • Deleting a directory will trigger an undeploy of the application with the removal of any associated context file and work directory.
  • Updating a WAR file will trigger an undeploy of the application with the removal of any associated expanded directory, context file and work directory.
  • Updating a directory (not the directory contents) will trigger an undeploy of the application with the removal of any associated context file and work directory.

Exhaustive details: http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment

share|improve this answer
    
This is not a complete answer - see serverfault.com/faq#deletion –  Jenny D Feb 27 '13 at 13:01
    
:) please help yourself (seems the syntax highlighting works slightly different than in stackoverflow which deleted part of the answer before) –  Jan Zyka Feb 27 '13 at 14:41
    
The thing is that if you just add a link, the target of the link may disappear, making the answer useless. That's why serverfault.com encourages you to post the actual answer instead of just the link. And when I commented, the rest of the text wasn't visible. I'd still recommend actually posting a more complete response rather than a brief summary of the link. –  Jenny D Feb 27 '13 at 15:21
    
That's simply not true. The original answer contained (and still does) short summary of what you can find under the link. Without the link the answer still make perfect sense and together with the link you can find details. –  Jan Zyka Feb 27 '13 at 15:35
    
But I didn't plan to be offensive so sorry if it sounded like that :) I'm not much into this web, just was solving the same and wanted to share. –  Jan Zyka Feb 27 '13 at 15:38
show 5 more comments

Cant answer the Why bit.

However, This link states you can stop this by setting the autoDeploy="false" in server.xml

share|improve this answer
    
Under tomcat7 autoDeploy="false" makes no difference :( –  Joseph Lust Jun 11 '13 at 4:22
add comment

If you don't want autoDeploy feature, in production environments for instance, you may consider the following attributes in the conf/Catalina/localhost context file :

  • autoDeploy="false"
  • and deployXML="false"

autoDeploy="false" may not work alone because application context.xml (in META-INF) can override server.xml settings of autoDeploy.

  • The application's META-INF/context.xml will be used in development environment, with autoDeploy
  • The conf/Catalina/localhost context in production, without autoDeploy.

deployXML attribute documentation attribute documentation is worth reading (§ Standard Implementation).

Exhaustive autoDeploy user case, and when context is removed : i.e. application undeployed, user case is documented can be found here.

share|improve this answer
add comment

I honestly dont know what the reasoning behind Tomcat doing this is but try adding the following XML attribute to your context element

reloadable="false"

So your context could look something like this:

<Context path="/" docBase="/some/path/name" reloadable="false">
<!-- Context related stuff -->
</Context>

This should keep Tomcat from deleting the file

share|improve this answer
    
Unfortunately, that makes development harder as I would have to restart Tomcat after each build. –  staticsan Oct 20 '10 at 22:42
    
checkout jrebel to help with this in development: zeroturnaround.com/jrebel –  harmanjd Dec 8 '11 at 16:33
add comment

Have this problem to. Seems like when you replace your war it causes undeployment of the app which causes deletion of the context file. I don't have a work-around but would love to have one which is more convenient than reloadable=false

http://stackoverflow.com/questions/4032773/why-does-tomcat-replace-context-xml-on-redeploy

share|improve this answer
add comment

Sometimes it is necesary have different values for app in the server, for example a path to store uploaded files. In developer environment mabe we have something like this:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" reloadable="false">
     <Parameter name="rutaTrabajo" value="C:\Larry\Proyectos\app\rutaTrabajoxx" override="true"/>
</Context>

But in server the path is different:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/App/rutaTrabajo" override="true"/>
</Context>

I also have the same problem, tomcat deleting the context.xml( meapp.xml ) from conf/Catalina/localhost

To solve I use context.xml.default, in the same path I create a file called context.xml.default and inside a put config I want to held:

 cat context.xml.default
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/ParkiMeApp/rutaTrabajo" override="true"/>
</Context>

So ,when redeploying then app, the confir parameteres still there.

share|improve this answer
add comment

I realize this is an old thread, but I thought I would share what I found to fix this problem...

I had been having the exact same issue with my context.xml file for my desktop version of tomcat getting clobbered every time that I would deploy a new copy of the war file for my application.

The problem was due to the fact that I was making changes to this file directly on the filesystem. What fixed the problem was to edit the context.xml file via my Eclipse editor. Inside of my Eclipse, there's a "servers" project that once you expand it, you can see a handful of files, such as context.xml and server.xml. It appears that if you modify the files from here instead of going out to the filesystem, your changes are kept.

I found this solution in the following thread: https://www.liferay.com/community/forums/-/message_boards/message/16511799

I hope this helps someone else!

-StephenS

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.