On a personal side i tend to agree and like to have filesystem aligned with the deployment but I have to admit I saw path usage in META-INF/context.xml being quite large (in real deployments or in tooling integration).
I understand your example but it is true at each level including conflicting names in conf/* or server.xml. Now 90% of the usages are to strip the version from the war name (most build tools generate mywar-1.2.3[.QUALIFIER]. Maybe a flag to strip it on tomcat side would solve most of the cases and don't encourage that much the risk you refer to? Something like: <Context stripVersion="true" /> Wdyt? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2016-02-18 11:56 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 18/02/2016 10:42, Romain Manni-Bucau wrote: > > Hi guys, > > > > <Context path="/override" /> in <war>/META-INF/context.xml was used a lot > > for tomcat 6/7 and doesn't work anymore since tomcat 8 (didn't check if > it > > has been backported, can be). > > > > It is documented but I don't get why this feature has been removed. > > typically checking if path is null or not before setting ContextName > would > > be enough to keep the feature working. > > > > Do I miss anything? > > Yes. Consider the following: > > test1.war with META-INF/context.xml containing <Context path="/test2" /> > test2.war with no context.xml > > Put them both in the appBase of a default, running Tomcat instance. What > happens? > > If you want to change the path, either: > - change the name of the WAR > or > - locate it outside the appBase and put a context.xml file in > conf/<engine>/<host> > > The only place path is used is if the Context is defined in server.xml > and defining contexts in server.xml is strongly discouraged. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
