Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
spring-issuemaster opened this issue Jun 19, 2017 · 7 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jun 19, 2017

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:

Issue Links:

  • #20115 ResourceUtils.extractArchiveURL fails to work under Tomcat 8.0.41 with unpackWARs=false
@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jun 20, 2017

Stéphane Nicoll commented

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

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jun 21, 2017

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 3, 2017

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 3, 2017

Moritz Kleine commented

previous upload was incomplete

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 5, 2017

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 10, 2017

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-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 11, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.