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.)


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

  • 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 stackoverflow.com/questions/4032773/… – artemb Oct 28 '10 at 7:41

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

  • 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
  • 1
    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

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.


Cant answer the Why bit.

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

  • 1
    Under tomcat7 autoDeploy="false" makes no difference :( – Joseph Lust Jun 11 '13 at 4:22

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


So your context could look something like this:

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

This should keep Tomcat from deleting the file

  • 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

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!



The general issue as described by the title is covered by Re-deploy from war without deleting context which is still an open issue at this time.

There is an acknowledged distinction between re-deploy which does not delete the context, and deploy after un-deploy where the un-deploy deletes the context. The documentation was out of date, and the manager GUI still does not support re-deploy.


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"/>

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"/>

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"/>

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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