tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Date Mon, 06 May 2013 17:55:12 GMT
On 06/05/2013 16:08, Jesse Barnum wrote:
>>> If that's true, then why is the context.xml file no longer
>>> extracted in Tomcat 7? Leaving it in the application directory
>>> means that it's going to be overwritten (losing those
>>> customizations) every time the server admin redeploys my
>>> application, right? Doesn't that seem like a bad idea? Am I
>>> missing something?
>> Not everyone agrees with that view: 
> Mark, thanks for pointing me to that discussion thread - at least I
> understand now the rationale behind the copyXML attribute. I don't
> agree at all that it's default value is false instead of true.
> So to summarize, there are two conflicting problems:
> * An old extracted XML file that happens to have the same name as a
> newly deployed web application could cause problems and prevent that
> new application from deploying correctly, thus arguing for not
> extracting the context.xml from the web app (copyXML=false).
> * If a user customizes the XML file (inside the web app folder), then
> all of their customizations are irretrievably overwritten whenever a
> new version of the application is deployed, thus arguing for storing
> the context.xml in a separate folder and not overwriting it
> (copyXML=true).

You are missing the main argument for this change. Apps that ship *with*
configuration in context.xml packaged in the WAR need to be able to
update this configuration with a new version of the application.

> The current behavior (copyXML=false) is like the equivalent of losing
> your preferences in a desktop app every time you install an updated
> version. It seems self-evident that this is a Bad Thing.

That depends entirely on the use case.

> Many users of my application are directly interacting with Tomcat for
> the first time. While I can put all sorts of comments in my
> context.xml file instructing them on how to modify it, it's difficult
> to explain to them how (and why) to find the right spot in the
> server.xml file to change that attribute.
> Is there any point in filing a bug report to request that this
> attribute default to true? Or is it a done deal?

Right now, probably not.

There are a couple of issues in this area (the thread I referenced,
unpacking WARs outside the appBase into the appBase, lack of clarity on
exactly what the expected behaviour in any given scenario) that I am
actively working on. My rough plan is:
- document what I think should happen (as simply as possible - this is
proving to be the hard part as there are so many variables)
- present this to the community for discussion / feedback
- implement it for 8.0.x
- probably back-port it to 7.0.x

For you particular scenario I am considering allowing per Context
override of copyXML that would enable your app to work as you want in a
default Tomcat 7 install. Every new option, however adds to the overall
complexity so I am still working through this.

Watch this space.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message