Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 30 Nov 2005 09:23:57 -0800
From: Jan Luehe <Jan.Luehe@Sun.COM>
Subject: Re: getContext() - spec interpretation
In-reply-to: <438CBE1D.6020903@apache.org>
To: Tomcat Developers List <dev@tomcat.apache.org>
Reply-to: Jan.Luehe@Sun.COM
Message-id: <438DE02D.7090807@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214
References: <438615BF.9020102@apache.org> <438BC26B.5010805@sun.com>
 <438CBE1D.6020903@apache.org>

Mark,

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
>>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
> 
> 
> 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();
     uriMB.setString(uri);
     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.


Thanks,


Jan


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


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