Bug 114688 - Dispatching Application in non-ROOT webapp fails under Tomcat 4.0.6
Dispatching Application in non-ROOT webapp fails under Tomcat 4.0.6
Status: CLOSED WONTFIX
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity high
: ---
: ---
Assigned To: Randy Graebner
Jon Orris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-31 09:22 EST by Daniel Berrange
Modified: 2007-04-18 13:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-02 13:46:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2004-01-31 09:22:22 EST
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 Berrange 2004-01-31 09:24:29 EST
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 Berrange 2004-01-31 11:00:18 EST
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 13:01:06 EST
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 Berrange 2004-02-09 13:05:06 EST
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 16:30:21 EST
marking QA_READY based on above discussion
Comment 6 David Lawrence 2006-07-17 22:58:53 EDT
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.
Comment 7 Daniel Berrange 2006-09-02 13:46:12 EDT
Closing old tickets

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