Question

I’m using maven-tomcat-plugin to deploy a tapestry application on a tomcat6 server. The deployment process worked fine, but now I need to deploy it multiple times using different paths for production/development/testing/etc. environments, this is one by using maven profiles.

I’ve set the context path of one deployment profile to: /myapp/latest. The URL generated used to deploy looks like this:

http://example.com:8080/manager/deploy?path=%2Fmyapp%2Flatest&update=true

Tomcat uses some convention now: hash signs get replaced by slashes (# gets replaced by /) in the .war’s file name, to construct the url of the app. The war is unpacked to a folder which name is the war’s file name without the .war extension.

The application cannot be started, the reason seems quite clear from the logs:

Caused by: java.io.FileNotFoundException: /var/lib/tomcat6/webapps/myapp%23latest/WEB-INF/classes/de/myapp/services/AppModule.class (No such file or directory)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:120)
    at org.apache.tapestry5.internal.plastic.PlasticInternalUtils.getStreamForPath(PlasticInternalUtils.java:408)
    at org.apache.tapestry5.internal.plastic.PlasticInternalUtils.readBytecodeForClass(PlasticInternalUtils.java:370)

The path /var/lib/tomcat6/webapps/myapp%23latest/ doesn’t exists, it should be /var/lib/tomcat6/webapps/myapp#latest/ of course. %23 is a hash sign so I guess at some point it got url encoded. I can’t find much on this problem, just some similiar issue for tomcat7 involving double hashes, unfortunatly without any solution.

I could avoid this problem by not using sub paths but I know this one should work: I already used the same method in a grizzly/jersey project without any problems.

How can I set a sub path properly? Is there any way to tell the application to not encode the path? The tomcat plugin doesn’t seem to provide much options here, so is there any way to set the path in a configuration file like web.xml or context.xml?

Answer 1

Further to my comment, I think this may be due to a bug in Tapestry’s PlasticInternalUtils.getStreamForPath method. Here you’ll find:

if (url.getProtocol().equals("file"))
    {
        String urlPath = url.getPath();
        String decoded = urlPath.replaceAll("%20", " ");
        return new FileInputStream(new File(decoded));
     }

So spaces are dealt with but other escape sequences are not. I suggest filing a bug and look to build your own version of Tapestry with all escape sequences decoded using:

URLDecoder.decode(urlPath, "UTF-8")