Summary: | Error on .war deploy - archive malformed (on recent Tomcat releases) on IBM iSeries System i | ||
---|---|---|---|
Product: | Tomcat 6 | Reporter: | Jon E. <jon> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 6.0.32 | ||
Target Milestone: | default | ||
Hardware: | Other | ||
OS: | other |
Description
Jon E.
2011-02-08 17:59:01 UTC
That message is "expandWar.illegalPath" in org.apache.catalina.startup.ExpandWar. There are two places where it is checked there. Basically, it is if (!expandedFile.getCanonicalPath().startsWith( )) check. You will have to test what getCanonicalPath() returns for those paths on that server and why the test fails. This looks like a JVM bug at this point. I think the best we can do is add some debug logging to help track this down. If I add the looging to Tomcat 7, can you build Tomcat 7.0.x from svn and test? I modified the ExpandWar class to spit out the failed comparison values in the validate method right before the exception is thrown. After stuffing the modified class back into the Catalina.jar and testing the deployment again, I could see the problem appears to be with with case of the value of the root folder being returned by the getCononicalPath() method. I am currently working with IBM support on this issue, and will post back once we have a definitive answer. There is a theory as to the cause and we are in the process of verifying it. I will definitely post back here when we have a solid answer. btw - Konstantin's comment about the ExpandWar class really helped put me on the right track - thank you! The problem occurs when Tomcat (on the iSeries / System i / AS400) is started with a command line that has different case values than where the file system resides. We configured the IBM System i to start Tomcat with the following QShell command: qsh cmd('/Apache/apache-tomcat-6.0.32/bin/startup.sh') Yet the real name where Tomcat resides is: /apache/apache-tocmat-6.0.32/bin/startup.sh Deployment fails when they are not equal, even though Tomcat is running. In ExpandWar, when it compares the canonical paths, the expandedFile.getCononicalPath() value is the value that was used to start Tomcat, and the canonicalDocBasePrefix is set to the value of where the .jar file entries reside on the file system. /Apache/apache-tomcat-6.0.32/bin/startup.sh != /apache/apache-tomcat-6.0.32/bin/startup.sh Previously we were using Tomcat 6.0.20, which did not have this validation in class ExpandWar. On hosts that do not have case sensitive file systems, should the path names all be resolved to lower case before this check? WORK AROUND: On our system, we changed the command string that starts Tomcat to be exactly the same, case-for-case, as the directory in which it resides. When this is done, deployment works fine. Thank you for your help. - Jon That looks like a JVM bug. The canonical path should be be using the 'real' (lower case in your case) path. |