----- Original Message -----
From: "Mark Thomas" <[EMAIL PROTECTED]>
To: <[email protected]>
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
(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.
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();
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();
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
