tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationContext.java
Date Sun, 04 Apr 2004 18:18:31 GMT
Mark Thomas wrote:
> From: Remy Maucherat [mailto:remm@apache.org] 
> 
>>Mark Thomas wrote:
>>
>>>Fixing bug 13040 requires an additional patch that uses 
>>
>>equals() for the whole
>>
>>>algorithm. Hence the complications. This is what I was 
>>
>>discussing above.
>>
>>The matching rule can't be fully implemented AFAIK. I think 
>>the current 
>>algorithm is a nice compromise.
>>Please give examples where you think it's not good enough (and is 
>>worthwhile to support), but you will likely end up breaking 
>>other stuff.
> 
> 
> Consider a server with the following contexts configured:
> A: /
> B: /foo/
> C: /foo/bar/
> 
> Assuming cross-context is enabled, the current behaviour of getContext(String
> uripath) for different values of uri in each context is as follows:
> 
> Context uripath         result
> ------------------------------
> A       "/"             A
> A       "/foo/"         B
> A       "/foo/bar/"     C
> A       "/foo/bar/xxx/" C
> 
> B       "/"             A
> B       "/foo/"         B
> B       "/foo/bar/"     B
> B       "/foo/bar/xxx/" B
> 
> C       "/"             A
> C       "/foo/"         B
> C       "/foo/bar/"     C
> C       "/foo/bar/xxx/" C
> 
> The thing that really bothers me about this is how the return from
> getContext("/foo/bar/") and getContext("/foo/bar/xxx") varies depending on the
> context from which the call is made. I think this is bad.
> 
> To quote from the spec:
> "uripath - a String specifying the context path of another web application in
> the container."
> 
> My proposal is to change getContext to provide the following behaviour:
> 
> Context uripath         result
> ------------------------------
> A       "/"             A
> A       "/foo/"         B
> A       "/foo/bar/"     C
> A       "/foo/bar/xxx/" null
> 
> B       "/"             A
> B       "/foo/"         B
> B       "/foo/bar/"     C
> B       "/foo/bar/xxx/" null
> 
> C       "/"             A
> C       "/foo/"         B
> C       "/foo/bar/"     C
> C       "/foo/bar/xxx/" null
> 
> I know that making this change will break a watchdog test but my reading of the
> spec is that the current behaviour is wrong.

Well, this breaks the spec, so this is not acceptable. The getContext 
method accepts a String which is not the exact context path.

For the example above, I've had trouble with the case B -> C as well. 
Thanks for giving it, it makes me remind everything.

> A number of users have indicated, via bugzilla, that the current behaviour is
> causing them problems.

Yes, but what you propose would cause even more users to come out and 
complain. A better patch is needed (although I don't quite know how to 
write it).

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message