You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2016/02/18 11:42:41 UTC
Context path: any technical reason to ignore it?
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?
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>
Re: Context path: any technical reason to ignore it?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2016 11:16, Romain Manni-Bucau wrote:
> 2016-02-18 12:02 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
>
>> 2016-02-18 13:42 GMT+03:00 Romain Manni-Bucau <rm...@gmail.com>:
>>> 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?
>>
>>
>> The "path" attribute is allowed only when Context element is declared
>> in server.xml. In all other cases it is ignored in Tomcat
>> 5.5/6.0/7.0/8.0/9.0 as far as I remember (for the last ~5 years). It
>> does not work in 6/7, contrary to your claim.
>>
>>
> Seems true, saw it a lot in tomcat 7 apps and assumed it was there so used.
> Was probably silently ignored.
>
>
>>
>> The main reasons are reducing ambiguity and implementation of
>> (auto)deployment. Note that
>>
>> 1. There are several steps that occur before context.xml is read.
>> 2. Deployment is protected by a lock keyed by web application name or
>> path. Look for "serviced", "isServiced".
>>
>>
> Should still be doable when constructing the StandardContext and before it
> is added to the host. Just means the standard context needs to be built and
> check can't be done just on filename but I don't see it as a blocker.
>
> I'm not a big fan of this (potential) feature but I have to admit it can
> save you some headache and time when you don't control the full server or
> deployment process. In cloud environments it would also be a simple and
> potentially "tomcat-standard" way to configure the path.
>
> Any hope to get the feature?
None.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Context path: any technical reason to ignore it?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-02-18 12:02 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
> 2016-02-18 13:42 GMT+03:00 Romain Manni-Bucau <rm...@gmail.com>:
> > 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?
>
>
> The "path" attribute is allowed only when Context element is declared
> in server.xml. In all other cases it is ignored in Tomcat
> 5.5/6.0/7.0/8.0/9.0 as far as I remember (for the last ~5 years). It
> does not work in 6/7, contrary to your claim.
>
>
Seems true, saw it a lot in tomcat 7 apps and assumed it was there so used.
Was probably silently ignored.
>
> The main reasons are reducing ambiguity and implementation of
> (auto)deployment. Note that
>
> 1. There are several steps that occur before context.xml is read.
> 2. Deployment is protected by a lock keyed by web application name or
> path. Look for "serviced", "isServiced".
>
>
Should still be doable when constructing the StandardContext and before it
is added to the host. Just means the standard context needs to be built and
check can't be done just on filename but I don't see it as a blocker.
I'm not a big fan of this (potential) feature but I have to admit it can
save you some headache and time when you don't control the full server or
deployment process. In cloud environments it would also be a simple and
potentially "tomcat-standard" way to configure the path.
Any hope to get the feature?
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Context path: any technical reason to ignore it?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2016-02-18 13:42 GMT+03:00 Romain Manni-Bucau <rm...@gmail.com>:
> 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?
The "path" attribute is allowed only when Context element is declared
in server.xml. In all other cases it is ignored in Tomcat
5.5/6.0/7.0/8.0/9.0 as far as I remember (for the last ~5 years). It
does not work in 6/7, contrary to your claim.
The main reasons are reducing ambiguity and implementation of
(auto)deployment. Note that
1. There are several steps that occur before context.xml is read.
2. Deployment is protected by a lock keyed by web application name or
path. Look for "serviced", "isServiced".
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Context path: any technical reason to ignore it?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
> <chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Context path: any technical reason to ignore it?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-02-18 17:20 GMT+01:00 Christopher Schultz <chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Context path: any technical reason to ignore it?
Posted by 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.
> 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?
> 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.
- -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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Context path: any technical reason to ignore it?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2016 11:00, 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).
>
> I understand your example but it is true at each level including
> conflicting names in conf/* or server.xml.
No it isn't.
You can't have conflicting names in conf and/or appBase.
server.xml always takes priority so no conflict either.
> 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?
No need. The version marker can be used for that:
mywar##1.2.3[.QUALIFIER].war
Mark
>
>
>
> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Context path: any technical reason to ignore it?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Context path: any technical reason to ignore it?
Posted by 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org