Bug 65226 - The StandardJarScanner extract wrong jar name and cause duplicate jar scan
Summary: The StandardJarScanner extract wrong jar name and cause duplicate jar scan
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.106
Hardware: All All
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2021-04-09 00:59 UTC by Lynx
Modified: 2021-04-09 20:47 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Lynx 2021-04-09 00:59:39 UTC
The StandardJarScanner is used to process when start scan the WebFragment. It first scan for all jars in WEB-INF/lib and then scan the whole classpath from all classloader.
The first scan went through correctly (https://github.com/apache/tomcat/blob/7.0.x/java/org/apache/tomcat/util/scan/StandardJarScanner.java#L164).

The second scan also went across the WEB-INF/lib and use this condition: https://github.com/apache/tomcat/blob/7.0.x/java/org/apache/tomcat/util/scan/StandardJarScanner.java#L229-L230 to determine if this jar is already scanned.

The problem happens when in the jar path, there is a ".jar" inside it, for example: file:/Users/lynx/myproject/.jarvis/jarvisproject/WEB-INF/lib/mylibrary.jar (url.toString() form)

The root cause I believe is due to this line: https://github.com/apache/tomcat/blob/7.0.x/java/org/apache/tomcat/util/scan/StandardJarScanner.java#L362, which only scan for the ".jar" suffix from the first found and return the index. There is some path in my server that contains a ".jar" in the path of a jar and breaks this logic.

Due to the condition doesn't met in StandardJarScanner, the webfragment is being scanned twice and cause a validation failure with some stacktrace like following:
  INFO | jvm 1 | 2021/04/08 15:46:00 | Caused by: java.lang.IllegalArgumentException: More than one fragment with the name [myfragment] was found. This is not legal with relative ordering. See section 8.2.2 2c of the Servlet specification for details. Consider using absolute ordering.
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.deploy.WebXml.orderWebFragments(WebXml.java:2338)
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1228)
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:888)
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:388)
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5536)
INFO | jvm 1 | 2021/04/08 15:46:00 | at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)

I would think a "lastIndexOf" is better fit but I'm not sure if this can cover all the cases.
Comment 1 Remy Maucherat 2021-04-09 07:32:55 UTC
I think you are right, since the 8.5 code is now:
Comment 2 Remy Maucherat 2021-04-09 08:27:43 UTC
Switched to lastIndexOf like for 8.5, the fix will be in 7.0.109.
Comment 3 Lynx 2021-04-09 20:47:11 UTC
Thanks! Can you estimate the schedule for 109? I'm expecting the new release in my environment.