-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Romain,
On 2/18/16 11:36 AM, Romain Manni-Bucau wrote: > 2016-02-18 17:20 GMT+01:00 Christopher Schultz > <ch...@christopherschultz.net >> : > > 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. Okay. But Tomcat's configuration component won't currently veto a <Context> with a path under any circumstances. I'm proposing that it DOES veto <Context> + path when it's being loaded from a file (and not server.xml). >>>> 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. Okay. >>>> 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 would say that if you want to upgrade to a recent version of Tomcat, you'll have to change your deployment. Supporting risky and broken configurations just because customers used to misuse them is not something that makes any sense for Tomcat to do. >> 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. The headaches will go away if they deploy "properly". The tools are all there. Supporting a configuration that is 10 years old simply for continuity is not a good idea. Those people also probably still have debug="0" and <ResourceParam> in their config files. The whole conf/server.xml needs to be re-done with every major release, so this should not be a great barrier for admins who want to upgrade. >> 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. +1 If we aren't going to refuse to load the context, we may as well complain about it. So many people post to the list asking about how to "fix" INFO messages in their log... maybe we'll get people to clean-up their configurations /that/ way. >> - open a way to force it from the webapp even if it logs a >> warning (maybe a flag userForced). $ mv file.war realpath.war? Or use the file under conf/etc. I don't understand why this is so onerous for users. Also, now many TomEE users have 10-year-old deployments? (I ask about TomEE because you usually post here relating to TomEE-based requests.) >> 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. I still don't hear a compelling reason to modify the current configuration options. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbGF/4ACgkQ9CaO5/Lv0PD3hACfVT6dckd098MVflchD8j+5T9Y A5IAnRR4k520KiFWRq6LOx4Urx6ni+X4 =1+4o -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
