https://issues.apache.org/bugzilla/show_bug.cgi?id=47834
--- Comment #5 from Guillaume Sauthier <[email protected]> 2009-09-15 00:23:17 PDT --- (In reply to comment #4) > Thanks for the testing. > > > In tldScanWebInfLib(), when you get the resource paths from WEB-INF/lib, my > > jar > > file is there, but the String is of the form: "<something>.jar/". The > > trailing > > '/' is a problem because you test for ".jar" only. > That is expected. Exploded jar files should be dealt with > tldScanClassloaders(). You'll need to set the > org.apache.jasper.compiler.TldLocationsCache.SCAN_CLASSPATH system property as > well as ...SCAN_ALL_FILES and ...SCAN_ALL_DIRS I'm sorry, I didn't get the reason why there is a method to deal with WEB-INF/lib/*.jar content (excluding unpacked directories) and another one that scan the webapp classloader. Isn't it doing the job twice ? I mean the URLs we get from the ClassLoader are WEB-INF/classes and all the jars from WEB-INF/lib. I agree there are also the URLs from the parent's URLClassLoader, but in that case, it's not necessary to rescan the webapp's libraries, it should be sufficent to scan only the parent ClassLoaders. In that way of thinking, it appears that tldScanClassloaders() is not appropriate when dealing with unpacked jar libraries, they should be processed in tldScanWebInfLib(). Maybe you wanted to separate (using the SCAN_CLASSPATH flag) standard processing from tomcat specific "extension" ? WDYT ? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
