With Tomcat8, loading of resources located in jar fails

[svanbegin]

When upgrading a webapp based on StringTemplate4 from Tomcat7 to Tomcat8,
we were faced with a resource loading issue. The resources being located in a jar within a war.

Resource management module has been rewritten in Tomcat8 and as a side effect in StringTemplate, the root path now ends with a forward slash:

STGroupDir(st/tabs) found via CLASSPATH at jar:file:/opt/tomcat8/webapps/app/WEB-INF/lib/ui-impl.jar!/st/tabs/

StringTemplate now tries to find a resource with a corrupted (double slash) path:

jar:file:/opt/tomcat8/webapps/app/WEB-INF/lib/ui-impl.jar!/st/tabs//tabs_js.st doesn't exist

I created a derived class which is just a temporary workaround but illustrates how I solved this issue:

public class STGroupDirPatched extends STGroupDir {

public STGroupDirPatched(String dirName) {
    super(dirName);
    if (root != null && root.toString().endsWith("/")) {
        try {
            String url = root.toString();
            root = new URL(url.substring(0, url.length() - 1));
        } catch (MalformedURLException e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }
}

}

[thomasKalmar]

Isn't the Problem solvable by replacing usage of for example
f = new URL(root+prefix+unqualifiedFileName);
with
f = new URL(root, prefix+unqualifiedFileName);
see http://docs.oracle.com/javase/6/docs/api/java/net/URL.html#URL(java.net.URL,%20java.lang.String) for details. This should take care of the trailing /

[solussd]

This PR: #199 combined with constructing a STGroupFile using a url from a Classloader's getResource method should solve these kinds of issues.

Constructing paths for particular environments is likely to break in others (e.g., code packaged in a jar vs exploded at a directory).

[parrt]

I believe this was resolved with #207