tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Luehe <Jan.Lu...@Sun.COM>
Subject Re: getContext() - spec interpretation
Date Tue, 29 Nov 2005 02:52:27 GMT
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 
> ( 
> 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:

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

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?


> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message