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: >> http://tomcat.markmail.org/thread/snyk3c23zurz5lnq > > 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
