Classpath Resource URL handling still wrong with Tomcat 8.5.12 [SPR-15681]

[spring-projects-issues]

Moritz Kleine opened SPR-15681 and commented

When building WAR files with resources residing in /WEB-INF/classes the following exception is raised when starting the webapp in tomcat 8.5.12:

org.springframework.beans.factory.BeanDefinitionStoreException: I/O failure during classpath scanning; nested exception is java.io.FileNotFoundException: file:/opt/apache-tomcat-8.5.12/webapps/test.war$/WEB-INF/classes/com/acme/test (No such file or directory)
        at org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:323) ~[sp
ring-context-4.3.9.RELEASE.jar:4.3.9.RELEASE]
        at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:272) ~[spring-context-4.3.9.RELEASE.jar:4.3.9.RELEAS
E]
...

The very same setup used to work fine before https://bz.apache.org/bugzilla/show_bug.cgi?id=60728 and spring-projects/spring-boot#7949. At least we're using this packaging successfully with tomcat 7.0.x, <= 8.0.36 and websphere.

Known workarounds: Unpack webapp. Move resources to separate jar so that they are read from /WEB-INF/lib/test.jar instead of /WEB-INF/classes.

---

Affects: 4.3.9

Attachments:

• SPR-15681.zip (7.29 kB)
• SPR-15681.zip (3.08 kB)

Issue Links:

• ResourceUtils.extractArchiveURL fails to work under Tomcat 8.0.41 with unpackWARs=false [SPR-15556] #20115 ResourceUtils.extractArchiveURL fails to work under Tomcat 8.0.41 with unpackWARs=false

[spring-projects-issues]

Stéphane Nicoll commented

Can you please share a sample that reproduces the problem you're experiencing?

[spring-projects-issues]

Andy Wilkinson commented

The $/ separator in the URI looks a little suspicious to me. Have you used Tomcat's system property to customise the separator? Following the recent changes in Spring Framework, there should be no need to do so. Indeed, allowing customisation didn't actually fix the problem that it was intended to fix so it's been deprecated and will be removed again in Tomcat 9.

[spring-projects-issues]

Moritz Kleine commented

Example webapp attached. I get an exception when using the path separator

-Dorg.apache.tomcat.util.buf.UriUtil.WAR_SEPARATOR='$'

when not using the separator, only one of the resources matching the pattern classpath*:PATH/*.xml is loaded. The original exception that I posted arises in a closed source project that uses XML files to configure the application context. The point is, that all the files matching the pattern must be loaded. This used to work fine with tomcat 7.0 and 8.0 but fails with tomcat 8.5.

[spring-projects-issues]

Moritz Kleine commented

previous upload was incomplete

[spring-projects-issues]

Moritz Kleine commented

Also I wonder why tomcat 8.5.12 takes so much longer to deploy this rather simple example webapp than tomcat 7.0.72. Any ideas?

[spring-projects-issues]

Stéphane Nicoll commented

Moritz Kleine have you read Andy's comment above? This looks like more a Tomcat issue than a Spring issue, isn't it? If that property is going to be removed in tomcat 9, I guess you should stop first using it and then report whatever Spring-related issue left, if any.

[spring-projects-issues]

Moritz Kleine commented

Hi Stephane, yes, I read the comment and also knew about that tomcat property. To me it's still a spring issue as I tried to show with the uploaded example webapp. The webapp fails to load the application context correctly when being deployed to tomcat 8.5.12 running in unpackWARs=false mode.

[wagnerluis1982]

Hi. A little question. Is this issue still relevant?

[bclozel]

Closing this issue as outdated.