Hi Mark,
Mark Thomas wrote On 11/24/05 11:34,: > All, > > I have been looking at bug 13040 and reviewing the current > getContext() implementation. I saw Remy's comment from some time ago > when fixing some related bugs > (http://marc.theaimsgroup.com/?l=tomcat-dev&m=106008981803343&w=2) > that this would be better if the spec mandated that the parameter > passed to getContext() must be an exact match for a context path. > > Having read the 2.4 spec several times I am pretty sure that is does > say this, albeit not as directly as it might. I assume (perhaps > wrongly) that any changes in this area will generate a lot of debate > so I wanted to do the debate and then change the code. > > The key parts of the spec are: > SRV.14.2.8 ServletContext > <snip> > public ServletContext getContext(java.lang.String uripath) > <snip> > uripath - a String specifying the context path of another web > application in the container. > <snip> > > My interpretation is: > SRV.14.2.8 says the parameter is a context path > SRV.4.4 is very clear about what is context path is > > Therefore, getContext() must look for an exact match of uripath > against the context paths for the currently deployed web-apps. > > My proposal, therefore is to change the getContext() implementation to > look for an exact match. This is stricter than the current > implementation (and may cause problems for some users) but will fix a > number of odd behaviours including the one described in bug 13040. > > In the unlikely event that no-one disagrees with my interpretation, > I'll commit a fix over the weekend to TC4 and TC5. (The 2.3 spec has > the exact same wording.) I agree the current javadocs of ServletContext.getContext() are ambiguous, and I agree we need to present this case to the Servlet EG. Maybe there is a small chance to have this resolved in the Servlet 2.5 timeframe ... I think it would be more useful to have the "uripath" argument be interpreted as a full URI rather than a context root, and have ServletContext.getContext() determine the longest match of the given "uripath" with the context roots of any deployed contexts. Applied to the scenario described at: http://marc.theaimsgroup.com/?l=tomcat-dev&m=108109687130165&w=2 which assumes the following configured contexts: A: / B: /foo/ C: /foo/bar/ the above interpretation would give the following consistent results: 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/" C B "/foo/bar/xxx/" C C "/" A C "/foo/" B C "/foo/bar/" C C "/foo/bar/xxx/" C I agree the current behaviour, which "hides" any foreign contexts whose context roots match a subdir of the current context, is broken (in part because of the spec ambiguity), because it returns different results depending on the context from which the getContext() call is made. I don't see why we need to restrict "uripath" to be a context root in order to fix the current behaviour, though. As I said, returning the context whose context root has the longest match with the given "uripath" may make more sense. Would you agree? Jan > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
