Jasper scans both WEB-INF/lib and the class loader hierarchy for TLDs. StandardJarScanner does contains some logic that should avoid duplicate scanning:
if (processedURLs.contains(url)) {
// Skip this URL it has already been processed
continue;
}
However, the URLs from WEB-INF/lib and the classpath do not matching up. For example:
jar:file:/Users/awilkinson/dev/workspaces/spring/spring-boot/master/gh-6177/target/gh-6177-0.0.1-SNAPSHOT.war!/WEB-INF/lib/archaius-core-0.7.4.jar
jar:file:/Users/awilkinson/dev/workspaces/spring/spring-boot/master/gh-6177/target/gh-6177-0.0.1-SNAPSHOT.war!/WEB-INF/lib/archaius-core-0.7.4.jar!/
The first is returned from the ServletContext, the second comes from the class loader and is created by our JarFile implementation.
A couple of possibilities:
- Remove the
!/ suffix so that the URLs match
- Disable scanning of the classpath when launching an executable war. I think this will work as the war is intended to be self-contained, i.e. all of the TLDs should be packaged in the jar in
WEB-INF/classes or in a jar in WEB-INF/lib. Jasper will find them in either of these locations with also looking at the class path.
Jasper scans both
WEB-INF/liband the class loader hierarchy for TLDs.StandardJarScannerdoes contains some logic that should avoid duplicate scanning:However, the URLs from
WEB-INF/liband the classpath do not matching up. For example:The first is returned from the
ServletContext, the second comes from the class loader and is created by ourJarFileimplementation.A couple of possibilities:
!/suffix so that the URLs matchWEB-INF/classesor in a jar inWEB-INF/lib. Jasper will find them in either of these locations with also looking at the class path.