> -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Monday, May 06, 2013 4:01 PM > To: Tomcat Users List > Subject: Re: Why is context.xml no longer copied to > Catalina/localhost/myapp.xml? > > On 06/05/2013 21:35, Jesse Barnum wrote: > > On May 6, 2013, at 1:55 PM, Mark Thomas <ma...@apache.org> 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 > catalina.properties. > > 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] http://tomcat.apache.org/tomcat-7.0-doc/config/index.html (2nd > para) >
Which won't necessarily work for those of us who deploy into multi-tenant (multi-host) environments. For example, each context.xml might have a DB resource that has to be customized differently for each tenant/host. We certainly don't want to have to modify each context.xml with every new version that is produced, and they certainly could not use the same parameter for substitution. In that case, it's a one and done scenario, unless there are mods to the context.xml that are required by the new app release. Just one of those may varying scenarios you were talking about. Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
