tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: getContext() - spec interpretation
Date Sat, 26 Nov 2005 03:58:41 GMT

----- Original Message ----- 
From: "Mark Thomas" <>
To: <>
Sent: Thursday, November 24, 2005 11:34 AM
Subject: getContext() - spec interpretation

> 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.

I can't really dispute the interpretation of the spec, but the change is 
likely to break many more webapps then it fixes :(.

For TC 5, it would be nice to keep some backwards compatibility with 
something like:

     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();

> 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.)
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

This message is intended only for the use of the person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended
recipient, you may not read, copy, or distribute this message or any attachment. If you received
this communication in error, please notify us immediately by e-mail and then delete all copies
of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.

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

View raw message