On 18/02/2016 11:16, Romain Manni-Bucau wrote:
> 2016-02-18 12:02 GMT+01:00 Konstantin Kolinko <knst.koli...@gmail.com>:
> 
>> 2016-02-18 13:42 GMT+03:00 Romain Manni-Bucau <rmannibu...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to