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 https://github.com/spring-projects/spring-boot/issues/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: - #20115 ResourceUtils.extractArchiveURL fails to work under Tomcat 8.0.41 with unpackWARs=false
Comment From: spring-projects-issues
Stéphane Nicoll commented
Can you please share a sample that reproduces the problem you're experiencing?
Comment From: 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.
Comment From: 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.
Comment From: spring-projects-issues
Moritz Kleine commented
previous upload was incomplete
Comment From: 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?
Comment From: 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.
Comment From: 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.
Comment From: wagnerluis1982
Hi. A little question. Is this issue still relevant?
Comment From: bclozel
Closing this issue as outdated.