2016-02-18 17:20 GMT+01:00 Christopher Schultz <ch...@christopherschultz.net >:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Romain, > > On 2/18/16 6:00 AM, Romain Manni-Bucau wrote: > > 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). > > My preference would be to refuse to deploy an application with a > "path" attribute in a context.xml file. I haven't studied the code > well enough to know if it's possible (or reasonable) to know whether > the context is being configured based upon a context.xml file or from > within server.xml. > > It is possible AFAIK since the context.xml is created from a file in this case so we know which one. > > 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]. > > You mean when parallel deployment is NOT in use? > > Yep, parallel deployment would just add another suffix not influencing the path so the user doesnt care for the purpose of this thread. > > 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" /> > > I think this can still lead to undefined behavior when different web > applications overlap. We would have to either throw up our hands and > say "caveat deployor" or do a whole bunch of work to cover this edge cas > e. > > My vote would be to make users follow the existing rules. Removing a > version number from a WAR is easy: use conf/[engine]/[host]/[app].xml > and point it to the WAR file outside of the appbase. Done. > > Ok, now let's assume you control only the content of the .war you deploy (not the name since it is in a continuous deployment (or test) tooling, not the conf/ since it is a shared instance where you team doesnt have access. I think the cost of handling path - without breaking current conflicting name feature, just need few code changes - is worth the headache the users have. That said if really an issue for tomcat can you at least: - log an error (warn maybe?) saying path is ignored. Since there is a setter it is swallowed silently. - open a way to force it from the webapp even if it logs a warning (maybe a flag userForced). Today even forcing it manually through a listener it is ignored (= there is no real good moment in a prod instance - with other advanced listeners we don't control - to do so). Worse case having a server.xml flag can be a degraded option which can maybe be enough in practise. > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlbF7zoACgkQ9CaO5/Lv0PDdmwCgvFBMRFCb0OcnSpbX0G85JtUf > JoMAn3o31j2N4buEDStCSy8ikVAtMQ70 > =N+M6 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
