From: Remy Maucherat [mailto:[EMAIL PROTECTED]
> 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.
A number of users have indicated, via bugzilla, that the current behaviour is
causing them problems.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
