tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Istvan Devai <>
Subject Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Date Sun, 12 May 2013 21:32:18 GMT
On 05/06/2013 11:00 PM, Mark Thomas wrote:
> On 06/05/2013 21:35, Jesse Barnum wrote:
>> On May 6, 2013, at 1:55 PM, Mark Thomas <> wrote:
>>> 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.
>>> Mark
>> Make sense - thanks Mark.
>> I am sure that this would be out of scope, but if we pictured an ideal scenario,
it seems like there would be one configuration file that is tightly managed by the developer,
which is replaced when the app is redeployed, and a different configuration file that is intended
for end user customization, which is stored separately.
> The way to do that is to keep copyXML=false, parameterise [1] the
> META-INF/context.xml and then specify the necessary parameter values in
> That way the developer is free to manage META-INF/context.xml but any
> updates won't change the parameterised values.
> If the app doesn't fail to start if the parameters are set, it should be
> easy to add a ServletContextListener to make sure that it does.
> Mark
> [1] (2nd para)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Hi Thomas,

What if the customisation of context.xml is more than replacing a few 
simple variables? (for example: adding a valve)

My exact problem is described in the thread titled "proper context 
usage" from a few days before, but it essentially comes down to this:
I'd like to have a way to customize my app's context.xml in a way that 
it is retained while deploying-undeploying with the manager. See the 
mentioned thread for all ways I've tried to achieve this, without any 

Best regards,

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

View raw message