Why does tomcat replace context.xml on redeploy?

Asked 27/10, 2010 at 11:35 Answered 16/8, 2019 at 22:58

Documentation says if you have a context file here:

$CATALINA_HOME/conf/Catalina/localhost/myapp.xml

it will NOT be replaced by a context file here:

mywebapp.war/META-INF/context.xml

It is written here: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

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.

But everytime I re-deploy the war it replaces this myapp.xml with the /META-INF/context.xml!

Why does it do it and how can I avoid it?

Thanx

Audible answered 27/10, 2010 at 11:35 Comment(8)

Are you deploying manually or by an IDE plugin? – Halfassed 27/10, 2010 at 11:37

Personally, I wouldn't put a context.xml on the app server. I don't because I can seldom depend on having access to that file. I usually keep it local to my WAR file. – Banquet 27/10, 2010 at 11:48

I am deploying manually by putting mywebapp.war into $CATALINA_HOME/webapps. I keep my default settings in the WAR, but I want to be able to change those settings on a per-instance basis without modifying the war itself - that is why I want my context in the conf directory unchanged – Audible 27/10, 2010 at 12:12

See this recent chain on the mailing list mail-archive.com/[email protected]/msg81854.html – Ammadis 27/10, 2010 at 12:26

and recently on SF as well serverfault.com/questions/192784/… – Ammadis 27/10, 2010 at 12:28

thank you, JoseK. I seem to get it now. Undeployment causes removal of the context file – Audible 28/10, 2010 at 7:42

It might be a bit late, but you can have a look at this question to see a possible way to get around this issue: stackoverflow.com/questions/7142365 – Aide 25/8, 2011 at 14:7

This kind of questions should be up voted actually. – Nihility 21/2, 2012 at 21:31

Undeploy part of redeploy deletes app and the associated context.xml.

If you use maven tomcat plugin you can avoid deleting context.xml if you deploy your app with command like this:

mvn tomcat:deploy-only -Dmaven.tomcat.update=true

More info here: https://tomcat.apache.org/maven-plugin-2.0-beta-1/tomcat7-maven-plugin/deploy-only-mojo.html

You can use deploy-only with parameter mode to deploy the context.xml too.

Breann answered 12/12, 2011 at 10:5 Comment(1)

For folks following along at home: mvn tomcat7:deploy-only -Dmaven.tomcat.update=true -Dmaven.tomcat.mode=both -Dmaven.tomcat.contextFile=/foo/context.xml does the trick. Sad... but effective in tomcat7. – Agency 11/6, 2013 at 4:39

The short answer:

Just make the TOMCATHOME/conf/Catalina/localhost dir read-only, and keep reading for more details:

For quick deployment mode (Eclipse dynamic web project, direct Tomcat connection, etc.) on a local/non-shared Tomcat server you can just define your JDBC datasource (or any other 'web resource') using the META-INF/context.xml file inside the WAR file. Easy and fast in your local environment, but not suitable for staging, QA, or production.
For build deployment mode (usually for staging, QA, or prod), JDBC datasources and other 'web resources' details are defined by the QA/production team, not the development team anymore. Therefore, they must be specified in the Tomcat server, not inside the WAR file anymore. In this case, specify them in the file TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml (change Catalina by the engine, and localhost by the host, and CONTEXT by your context accordingly). However, Tomcat will delete this file on each deployment. To prevent this deletion, just make this dir read-only; in Linux you can type:
```
   chmod a-w TOMCATHOME/conf/Catalina/localhost
```
Voila! Your welcome.

The long answer

For historical reasons Tomcat allows you to define web resources (JDBC datasources, and others) in four different places (read four different files) in a very specific order of precedence, if you happen to define the same resource multiple times. The ones named in the short answer above are the more suitable nowadays for each purpose, though you could still use the others (nah... you probably don't want to). I'm not going to discuss the other ones here unless someone asks for it.

Alanalana answered 19/3, 2015 at 18:0 Comment(2)

This will not work when autodeploy is turned on for tomcat and you use tomcat7:undeploy it will complain that it cannot delete the Context Descriptor file – Atlantes 2/9, 2015 at 11:1

With this option, my deploys fail with the error message Cannot invoke Tomcat manager: Connection reset for the reason mentioned in Chad's comment. Instead, I used the option using context.xml from WEB-INF and optional (external) jndi resource from server.xml as described in the first answer here – Corallite 3/4, 2017 at 11:57

On tomcat7, also woth autoDeploy=false the file will be deleted on undeploy. This is documented and not a bug (althought it avoids good automated deployments with server-side fixed configuration).

I found a workaround which solved the problem for me:

create a META-INF/context.xml file in your webapp that contains
on the Server create a second context "/config-context" in server.xml and put all your server-side configuration parameters there
on the application use context.getContext("/config-context").getInitParameter(...) to access the configuration there.

This allows a per-host configuration that is independent of the deployed war.

It should also be possible to add per-context configurations by adding contexts like "/config-context-MYPATH". In your app you can use the context path oth the app to calculate the context path of the config app.

Snapper answered 4/10, 2012 at 15:24 Comment(1)

Why are the core tomcat devs so ignorant of best practices deployment? I lost basically a night to get a workaround here and all the work arounds are anti-patterns, but the TC devs are in denial and won't acknowledge that this is a sensible approach to install JNDI properites and sources on the host, not compile them into the SCM and war. issues.apache.org/bugzilla/show_bug.cgi?id=34840 – Agency 11/6, 2013 at 4:35

According to the documentation (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files) upon redeploy tomcat detects the deletion (undeploy) of your application. So it will start a cleanup process deleting the directory and xml also. This is independent of auto deployment - so it will happen upon redeployment through manager and modification of war also. There are 3 exceptions:

global resources are never deleted
external resources are never deleted
if the WAR or DIR has been modified then the XML file is only deleted if copyXML is true and deployXML is true

I don't know why, but copyXML="false" deployXML="false" won't help.

Secondly: Making the directory read only just makes tomcat throwing an exception and won't start.

You can try merging your $CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml, $CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml, etc files into $CATALINA_BASE/conf/context.xml (that works only if you make sure your application won't deploy its own context configuration, like myapp-1.xml)

If someone could tell what is that "external resources" that would generally solve the problem.

Exert answered 10/11, 2015 at 22:45 Comment(0)

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.

Winnah answered 16/8, 2019 at 22:58 Comment(0)

-1

Redeployment means two parts: undeployment and deployment.

Undeployment removes the conf/Catalina/yourhost/yourapp.xml because the

 <Host name="localhost" appBase="webapps" unpackWARs="true" 

           autoDeploy="true">      <!-- means autoUndeploy too!!! -->

 </Host>

Change the autoDeploy="false" and Tomcat has no order anymore to remove the conf/Catalina/yourhost/yourapp.xml.

There is an feature that allowes us to make those steps (undeploy/deploy) as one single step (redeploy) that do not remove the context.xml. This feature is available via the manager-text-interface, but the option is not available using the manager-html-interface. You might have to wait until the bug in tomcat is fixed. You can use the method described in this answer as an workaround.

Exemption answered 15/2, 2017 at 22:25 Comment(2)

Undeployment deletes the context. Re-deployment must not delete the context because it has nothing to do with un-deploying the application logically because that is not the intention of the operation as reflected by the word. It is unfortunate that this distinction is not made clear. Simply speaking, Redeployment is a word with its own meaning. – Winnah 16/8, 2019 at 22:56

@Winnah Changed answer, please check. – Exemption 18/8, 2019 at 6:21

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags