Bug 52293 - antiResourceLocking and unpackWARs
Summary: antiResourceLocking and unpackWARs
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.35
Hardware: PC All
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2011-12-06 18:54 UTC by Justin Miller
Modified: 2012-01-06 16:10 UTC (History)
0 users

ContextConfig.java (47.69 KB, text/plain)
2011-12-06 18:54 UTC, Justin Miller
ContextConfig.java (47.70 KB, text/plain)
2011-12-06 19:08 UTC, Justin Miller
differences (547 bytes, patch)
2011-12-06 19:36 UTC, Justin Miller
Details | Diff
2011-12-22_tc6_ContextConfig.java.patch (the same as above, but in unified diff format) (992 bytes, patch)
2011-12-22 09:42 UTC, Konstantin Kolinko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Miller 2011-12-06 18:54:27 UTC
Created attachment 28034 [details]

It appears that Tomcat is attempting to copy the WAR from the $CATALINA_HOME/webapps directory to the $CATALINA_HOME/temp directory without the .war extension (e.g., original docBase is $CATALINA_HOME/webapps/example.war and a new docBase of $CATALINA_HOME/temp/1-example ).  I think that line 973 in ContextConfig.java method antiLocking never evaluates correctly because the docBase gets set to the value of path on line 969, which removes the .war extension so the file ends up being $CATALINA_HOME/temp/1-example instead of 1-example.war.  
Additionally, applications with sub-context paths (e.g., foo#bar.war) never get deployed to temp correctly with antiResourceLocking="true" regardless of the unpackWARs setting because of the above scenario and because the docBase gets set to the context path in the antiLocking method which converts the # separator to /.  There appears to be a fix on line 882 of fixDocBase that converts the / character to # in the path but that doesn't make it to the antiLocking method.

Both 6.0.35 and 7.0.23 exhibit the same behaviour.  In 7.0.23, the docBase is changed back to the context path via the ContextName now instead of the context.getPath() but the result is the same.  Interestingly enough, there is a comment in the 7.0.23 source on line 750 that suggests the code to copy the .war file is never reached and that it's possibly a bug.  This code is never reached because the docBase is changed to the path without the .war extension.
Comment 1 Justin Miller 2011-12-06 18:58:27 UTC
Comment on attachment 28034 [details]

patch changes antiLocking method to convert '/' to '#' in docBase.
Comment 2 Justin Miller 2011-12-06 19:08:01 UTC
Created attachment 28037 [details]

forgot to include patch for the actual bug.  Line 974 now checks the originalDocBase for the ".war" extension and behaves appropriately.  The changing of '/' to '#' is secondary but also required to handle sub-pathed contexts
Comment 3 Justin Miller 2011-12-06 19:13:35 UTC
This bug presents when antiResourceLocking = "true" and unpackWARs = "false".  Additionally, regardless of the unpackWARs setting, sub-pathed contexts will not be copied correctly to the temp directory because no check exists in the antiLocking method for the sub-path
Comment 4 Konstantin Kolinko 2011-12-06 19:21:27 UTC
(In reply to comment #1)
> patch changes antiLocking method to convert '/' to '#' in docBase.

It is much easier to handle an issue when you submit a diff against previous version of a file, instead of attaching new file version as a whole.

The diff is several lines, a file is hundreds of lines. See the following pages:


Comment 5 Justin Miller 2011-12-06 19:36:54 UTC
Created attachment 28038 [details]

diff of patched antiLocking method with 6.0.35 version
Comment 6 Mark Thomas 2011-12-21 19:29:10 UTC
Fixed in trunk and will be included in 7.0.24 onwards.
Comment 7 Mark Thomas 2011-12-21 19:31:43 UTC
Proposed for 6.0.x
Comment 8 Konstantin Kolinko 2011-12-22 09:42:04 UTC
Created attachment 28097 [details]
2011-12-22_tc6_ContextConfig.java.patch (the same as above, but in unified diff format)

The same as Justin Miller's patch, but now in Unified diff format.
It is against tc6.0.x.
Comment 9 Konstantin Kolinko 2012-01-06 16:10:34 UTC
Fixed in 6.0 with r1228244 and will be in 6.0.36.