Description of problem:
The A-Z application lives in its own webapp 'ccm-ldn-atoz', so when
requests for /ccm/atoz/ come in, BaseDispatcher tries to forward on to
the /ccm-ldn-atoz/ context. This works fine on Resin, however, on
Tomcat 4.0.6 it always results a 404. After much debugging I
discovered that the call
Web.getServletContext().getContext("/ccm-ldn-atoz/") is always
returning the root context. Very bogus, so I got out the Tomcat source
and looked at the getContext(String uri) method:
String contextPath = context.getPath();
contextPath = contextPath + "/";
if ((contextPath.length() > 0) &&
In pseudo code, this is doing:
1. Get the current servlet context's path (ie, "" since this is the
2. Append '/' to ensure that /foo doesn't match /foobar
3. If the request URI starts with current context path return
Step 3 is where the fatal flaw is, because it means that you can
*NEVER* get hold of a servlet context mapped to a sub-URI of the
Since the ROOT context is mapped at "/", no matter what you pass in
you will always be given back the current context :-( This makes the
ServletContext#getContext(String uri) method useless and there is no
other API for getting a ServletContext.
This bug is not fixed until Tomcat 4.1.20 :-(
Version-Release number of selected component (if applicable):
Steps to Reproduce:
cf. this bugzilla discussion on the issue
Even with the patch 1.41 applied from their CVS repository,
getContext(String uri) is only fixed for the ROOT context. If you have
a context at /foo, and use it to request /foo/bar you will still be
given back the context for /foo. You'll need to request /foo/bar from
the ROOT context in order to get expected results.
I've added a temporary hack workaround in p4 39948. This maintains an
explicit ServletContext, URI mapping which the dispatcher uses in
preference. I've tested this on Resin 2.1.10 and Tomcat 4.0.6 and
verified it works for apps in ROOT webapp & those in their own webapp.
We should still review &/ alter this in next week post release when
we've got more relaxed time frames.
Richard asked me to take a look at this change. I (a) don't see an
alternative solution to Dan's and (b) I think his implementation is
about as straightforward as it gets. Dan, just to check, did you have
an issue in mind when you suggested reviewing the change?
I couldn't see an alternative soluition either, but just really wanted
someone else to take a look at it in case I was missing something.
There is of course the other option of saying CCM requires Tomcat >=
4.1.20, but that's not too friendly.
marking QA_READY based on above discussion
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.
Closing old tickets