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 Wed, 30 Nov 2005 17:23:57 GMT

Mark Thomas wrote On 11/29/05 12:46,:
> Jan,
> Jan Luehe wrote:
>>Hi Mark,
> <snip>
>>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.
> <snip>
>   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?
> I have just re-read the spec keeping score of number of times the 
> wording suggests an exact match or a longest match. The result was a 
> draw so I am happy to interpret it either way. Given that the longest 
> match makes the most sense to me and won't break any existing 
> functionality I will take this approach until the EG issues some 
> clarification. Hopefully they will clarify it the "right" way.

Makes sense.

So it seems we could apply the patch proposed by Bill to achieve the new
semantics of getContext():

     MessageBytes uriMB = new MessageBytes();
     MappingData md = new MappingData();
     MessageBytes serverName = request.getCoyoteRequest().serverName();
     request.getConnector().getMapper().map(serverName, uriMB, md);
     if(md.context == null) {
        return null;
     return ((Context)md.context).getServletContext();

I've rewritten the javadocs of getContext(), as follows:

     * Returns the <code>ServletContext</code> object to which the
     * specified URI has been mapped.
     * <p>This method allows servlets to gain access to foreign servlet
     * contexts deployed on the same container, from which
     * {@link RequestDispatcher} objects may be obtained.
     * A servlet context is considered foreign to a servlet if it is
     * different from the servlet's own servlet context.
     * <p>The given URI must be begin with "/".
     * <p>A security conscious servlet container may return
     * <code>null</code> if the specified URI maps to a foreign context.
     * @param uripath The URI to map
     * @return The <code>ServletContext</code> to which the given URI
     * has been mapped, or null if the given URI does not map to any of
     * the servlet contexts deployed on the container, or if the URI
     * maps to a foreign context and access to foreign contexts has been
     * disabled by the container
     * @see RequestDispatcher
    public ServletContext getContext(String uripath);

If we all agree, I will send this proposal to the Servlet EG.



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

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

View raw message