-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Resource resolution may fail in executable war that embeds Tomcat #7949
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
Comments
Thanks for the sample. This looks like a Tomcat bug. It's very similar to #7360 but doesn't appear to be exactly the same as overriding the Tomcat version to 8.5.9 (which fixes #7360 at the cost of some other problems) doesn't fix your sample. Also, using Boot 1.4.1.RELEASE but overriding Tomcat's version to 8.5.9 also causes the problem, i.e. it breaks when the only difference is the version of Tomcat that's being used. |
It works with Spring Boot 1.4.3.RELEASE and Tomcat 8.5.5 (the version of Tomcat used by 1.4.1.RELEASE). |
The problem is caused by a change in how Tomcat handles URLs for 8.5.5
8.5.6 and later
Note the change from The path for the resource is ultimately passed into The change in Tomcat's behaviour was introduced in the fix for issue 60087. |
@markt-asf @violetagg The switch to using |
Unfortunately, we are limited to characters that Java permits to be used in a URL. We previously tried to use
Ideally we want a character that is unlikely to appear in a file name (particularly at the end) and does not have a special meaning that could conflict when using it in combination with / in a URI to mark the start of the internal WAR path. There look to be a couple of potential candidates but I think a broader discussion is warranted to ensure any choice doesn't create a regression for some other group of users. I'll start something on the dev list. |
Thanks, Mark. Here's the thread on the dev list for anyone who wants to follow the discussion. |
@markt-asf The discussion on the mailing list seems to have fizzled out. Where do things stand with this now? |
It is one of many things on the TODO list. I suspect making it configurable will be the way to go. Probably best if you open a Bugzilla issue and reference the mailing list discussion to make sure this doesn't get lost in amongst everything else. |
8.5.12 introduces a System property, |
It doesn't look like 8.5.12 will be available in time. Moving to 1.4.6 |
8.5.12 release has been promoted (voting passed Mar 13 https://www.mail-archive.com/dev@tomcat.apache.org/msg115929.html): Will this fix be included in 1.5.3 as well besides 1.4.6? |
Yes. Fixes in 1.4.x are always merged forwards into 1.5.x and master. |
This remains blocked while we work out SPR-15332 |
Thanks changes made for SPR-15332 mean that this will be fixed by upgrading to Spring Framework 4.3.8 without any need to customise the separator that Tomcat uses. |
The Tomcat separator customization appears to be a fail anyway. I have a spring-boot app packaged as ROOT.war in the webapps directory. Works in 8.0.36, fails in 8.0.41 (which we already knew). In 8.0.42, referring to this commit I tried the following:
I see in the startup logs:
This is followed by a fatal exception:
I know this is really for the Tomcat team but most of the useful information about this issue does appear to be documented here. |
I'm not surprised '!' fails. It will conflict with the JAR separator. Try $. |
$ reverts to the original exception (also tried a few other benign looking symbols like ^ _ with the same result): Confirmation:
Exception:
Possibly late information but... when this works (back in 8.0.36) the call to
When it fails in later versions the only difference is the first collection element:
|
Thanks for testing. Given that this isn't fixing the problem it is meant to fix and that Spring Boot doesn't require this fix any longer I am going to remove this feature from 9.0.x and deprecate it in 8.x |
Just as a tip to others that may not be in control of the Tomcat version that they use: unpacking the spring-boot fat jar into webapps/ROOT appears to work around the original issue. |
Is this issue resolved? I am using 1.5.6.RELEASE but when i run my fat jar (ie. java -jar app.jar) and use ResourceUtils.getFile(this.getClass().getResource(pathToFiles) I still get the exception: |
That's to be expected given that you are calling |
@wilkinsona make sense thanks for pointing me in the right direction. I will access the required file via java.util.jar.JarFile. The only weird thing is that when running the SpringBoot app via Eclipse (STS) i don't need to do access the JAR, I guess since its no running the fat jar. I wish there was a more abstract way of doing this (maybe inputstreams???). The ResourceUtils.getFile() is easily understood and it works well when working via Eclipse but for obvious reasons (ie. the File inside a jar is not a resource) when working with the jar, it will not work. |
When packaging a spring boot web application as a WAR, then starting it as a standalone app using
java -jar example.war
, the application seems to start fine, but when trying to open any page I get a status 500 Internal Server Error. The log shows the stacktrace below.This is broken in 1.4.2.RELEASE, 1.4.3.RELEASE and 1.5.0.RC1. It works fine in 1.4.1.RELEASE and older.
I've prepared a minimal case, found at https://github.com/jvdmr/spring-boot-war-example
Stacktrace:
The text was updated successfully, but these errors were encountered: