On 30/10/2014 00:33, Konstantin Kolinko wrote: > 2014-10-29 17:42 GMT+03:00 <ma...@apache.org>: >> Author: markt >> Date: Wed Oct 29 14:42:01 2014 >> New Revision: 1635154 >> >> URL: http://svn.apache.org/r1635154 >> Log: >> URLs may be added directly to the web application's class path. ensure that >> they are scanned if a StandardJarScanner is configured to scan the class >> path. >> >> Added: >> >> tomcat/trunk/test/org/apache/tomcat/util/scan/TestStandardJarScanner.java >> (with props) >> Modified: >> tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java >> tomcat/trunk/test/org/apache/catalina/filters/TesterServletContext.java >> tomcat/trunk/webapps/docs/changelog.xml >> > > (It was a fix for > https://issues.apache.org/bugzilla/show_bug.cgi?id=57153 > ) > > > I suspect that this change is the trigger for breakage of > org.apache.jasper.servlet.TestTldScanner test.
I agree. I was looking at this last night and reached the same conclusion. >From memory, before the WebResource refactoring that simplified this code there was a check that ensured that WEB-INF/classes and JARs from WEB-INF/lib were excluded from the class path scan. I think that check needs to be restored a) to address this issue and b) to make the scan more efficient. > The logs are: > > http://ci.apache.org/projects/tomcat/tomcat8/logs/1635250/TEST-org.apache.jasper.servlet.TestTldScanner.NIO2.txt > > [[[ > Caused by: java.lang.IllegalArgumentException: The resource path > [null/META-INF/bug55807.tld] is not valid > at > org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:250) > at > org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:212) > at > org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:206) > at > org.apache.catalina.core.ApplicationContext.getResource(ApplicationContext.java:533) > at > org.apache.catalina.core.ApplicationContextFacade.getResource(ApplicationContextFacade.java:199) > at org.apache.jasper.compiler.TldCache.getLastModified(TldCache.java:128) > at org.apache.jasper.compiler.TldCache.<init>(TldCache.java:70) > at > org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:113) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5185) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > ... 7 more > ]]] > > > I debugged with breakpoint at "TldResourcePath(URL url, String > webappPath, String entryName)" constructor (TldResourcePath: line 65) > > It is called with the following arguments: > - url: file:/<...>trunk/test/webapp/WEB-INF/classes/META-INF/bug55807.tld > - webappPath: null/META-INF/bug55807.tld > - entryName: null > > Stacktrace at constructor call: > [[[ > Daemon Thread [localhost-startStop-1] (Suspended (breakpoint at line > 65 in TldResourcePath)) > owns: StandardContext (id=33) > TldResourcePath.<init>(URL, String, String) line: 65 > TldResourcePath.<init>(URL, String) line: 54 > TldScanner$TldScannerCallback$1.visitFile(Path, > BasicFileAttributes) line: 342 > TldScanner$TldScannerCallback$1.visitFile(Object, > BasicFileAttributes) line: 1 > FileTreeWalker.walk(Path, int, List<AncestorDirectory>) line: 135 > FileTreeWalker.walk(Path, int, List<AncestorDirectory>) line: 199 > FileTreeWalker.walk(Path) line: 69 > Files.walkFileTree(Path, Set<FileVisitOption>, int, > FileVisitor<Path>) line: 2602 > Files.walkFileTree(Path, FileVisitor<Path>) line: 2635 > TldScanner$TldScannerCallback.scan(File, String, boolean) line: 323 > StandardJarScanner.process(JarScanType, JarScannerCallback, URL, > String, boolean) line: 315 > StandardJarScanner.scan(JarScanType, ServletContext, > JarScannerCallback) line: 227 > TldScanner.scanJars() line: 240 > TldScanner.scan() line: 99 > JasperInitializer.onStartup(Set<Class<?>>, ServletContext) line: 103 > StandardContext.startInternal() line: 5185 > StandardContext(LifecycleBase).start() line: 150 > ContainerBase$StartChild.call() line: 1409 > ContainerBase$StartChild.call() line: 1 > FutureTask<V>.run() line: 262 > ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1145 > ThreadPoolExecutor$Worker.run() line: 615 > Thread.run() line: 745 > ]]] > > Note the following lines in stacktrace: > > TldScanner$TldScannerCallback.scan(File, String, boolean) line: 323 > StandardJarScanner.process(JarScanType, JarScannerCallback, URL, > String, boolean) line: 315 > StandardJarScanner.scan(JarScanType, ServletContext, > JarScannerCallback) line: 227 > > At StandardJarScanner line 227 it is: > [[[ > process(scanType, callback, urls[i], null, isWebapp); > ]]] > > where "null" is explicitly passed as the value of "webappPath". > The "null" value is passed into StandardJarScanner.process() and > further into TldScanner$TldScannerCallback.scan(), see the above 3 > lines of stacktrace. > > TldScanner line 338: > String resourcePath = webappPath + "/" + subPath; > > results in "null/" prefix. > > > > Note 2: At that point in time when the above stacktrace etc. happens, > it is the second time when TldResourcePath() constructor is called for > bug55807.tld file. > > At some earlier time TldResourcePath(URL url, String webappPath, > String entryName) is called with correct webappPath value, > > /WEB-INF/classes/META-INF/bug55807.tld > > I think that the second call with null//META-INF/bug55807.tld is a > result of this commit. > > It may be that this bug did exist before, but that code path in > StandardJarScanner just was not executed. That null doesn't look right. One of this morning's jobs is to look at that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
