tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Barnum <>
Subject Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Date Mon, 06 May 2013 15:08:03 GMT

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

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.

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?

--Jesse Barnum, President, 360Works
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message