Bug 114688 - Dispatching Application in non-ROOT webapp fails under Tomcat 4.0.6
Summary: Dispatching Application in non-ROOT webapp fails under Tomcat 4.0.6
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other
Version: nightly
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Randy Graebner
QA Contact: Jon Orris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-31 14:22 UTC by Daniel Berrangé
Modified: 2007-04-18 17:02 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-02 17:46:12 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2004-01-31 14:22:22 UTC
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();

  if (!contextPath.endsWith("/"))
    contextPath = contextPath + "/";

  if ((contextPath.length() > 0) && 
      (uri.startsWith(contextPath))) {
    return (this);
  }

In pseudo code, this is doing:

  1. Get the current servlet context's path (ie, "" since this is the
ROOT)
  2. Append '/' to ensure that /foo doesn't match /foobar 
  3. If the request URI starts with current context path return
current context

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

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 :-( 

http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Daniel Berrangé 2004-01-31 14:24:29 UTC
cf. this bugzilla discussion on the issue

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040

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.

Comment 2 Daniel Berrangé 2004-01-31 16:00:18 UTC
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.


Comment 3 Justin Ross 2004-02-09 18:01:06 UTC
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?

Comment 4 Daniel Berrangé 2004-02-09 18:05:06 UTC
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.


Comment 5 Richard Li 2004-02-12 21:30:21 UTC
marking QA_READY based on above discussion

Comment 6 David Lawrence 2006-07-18 02:58:53 UTC
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.

Comment 7 Daniel Berrangé 2006-09-02 17:46:12 UTC
Closing old tickets



Note You need to log in before you can comment on or make changes to this bug.