Bug 46261 - Context with %2F in name causes tomcat crash on shutdown
Summary: Context with %2F in name causes tomcat crash on shutdown
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.18
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 46262 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-21 08:34 UTC by Joe Kislo
Modified: 2009-01-31 00:42 UTC (History)
0 users



Attachments
Proposed patch (1.15 KB, patch)
2008-11-21 08:35 UTC, Joe Kislo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Kislo 2008-11-21 08:34:21 UTC
Context with %2F in name causes tomcat crash on shutdown

Several years ago I worked on integrating tomcat 5.5 into our web application management infrastructure.  During the process I fixed several tomcat 5.5 bugs, but apparently never sent the fixes upstream.  Oops.

Our application needs to be deployed to create a URL that looks like this:

/product/customername/servlet

I worked with several people on IRC to get tomcat5.5 to do this.  We had previously been using the path= parameter in the context xml file element with tomcat 4.1.  Unfortunately, it appears this feature was removed from tomcat5.5, and tomcat5.5 does not recurse into subdirectories when reading .xml context files.  The recommendation on IRC (after several suggestions which would not work for our environment) was to put %2F in the context xml file's name.  Such as this

product%2Fcustomername.xml

This does work, however when you try to shutdown tomcat 6.0.18, you will get this crash:

Nov 9, 2008 10:56:17 PM org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8180
Nov 9, 2008 10:56:18 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Nov 9, 2008 10:56:18 PM org.apache.catalina.startup.HostConfig undeployApps
WARNING: Error while removing context [/product%2Fcustomername]
java.lang.NullPointerException
        at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:915)
        at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1191)
        at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1162)
        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
        at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1086)
        at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1098)
        at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448)
        at org.apache.catalina.core.StandardService.stop(StandardService.java:584)
        at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744)
        at org.apache.catalina.startup.Catalina.stop(Catalina.java:628)
        at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:671)
Nov 9, 2008 10:56:18 PM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8180
Comment 1 Joe Kislo 2008-11-21 08:35:26 UTC
Created attachment 22910 [details]
Proposed patch
Comment 2 Joe Kislo 2008-11-21 08:36:13 UTC
I have attached a patch that I have been using to work around this issue. It modifies findChild to decode the name if the initial lookup fails.
Comment 3 Mark Thomas 2008-11-21 08:45:56 UTC
The correct way to do this in 6.0.18 is to use the # character rather than %2F.

%2F should be interpreted literally.
Comment 4 Mark Thomas 2008-12-26 15:51:04 UTC
This has been fixed in trunk. I want to do some more testing of this and look at bug 46262 before proposed anything for 6.0.x
Comment 5 Mark Thomas 2008-12-28 15:59:35 UTC
*** Bug 46262 has been marked as a duplicate of this bug. ***
Comment 6 Mark Thomas 2008-12-28 16:03:37 UTC
I couldn't break my fix in my testing so I have proposed the fix for 6.0.x
Comment 7 Mark Thomas 2009-01-31 00:42:50 UTC
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.