-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Resource handling is inconsistent across different embedded containers #8299
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
ExpectationsFat warFor war files, we're interested in resources in these three locations:
Accessing resources via HTTP and via the servlet context (SC) should have the following results:
Fat jarFor jar files, we're interested in resources in these locations:
Accessing resources via HTTP and via the servlet context should have the following results:
Actual behaviourFat war
(1) - Tomcat only works when Jasper in on the classpath Fat jar
(1) - Tomcat only works when Jasper in on the classpath |
We should consider configuring the containers such that they can serve resources from |
The changes made for spring-projectsgh-8299 attempted to make static resource handling consistent across Jetty, Tomcat, and Undertow. They did so for application's launched using JarLauncher or WarLauncher but did not consider application's launched in an IDE or using spring-boot:run in Maven or bootRun in Gradle. Running in an IDE or via Maven or Gradle introduces two new resource locations: - Jars on the classpath with file protocol URLs (they are always jar protocol URLs when using either launcher) - Directories on the classpath from a project that is depended upon and contains resources in META-INF/resources This commit updates the factories for all three containers to handle these new resources locations. The integration tests have also been updated.
The changes made for gh-8299 attempted to make static resource handling consistent across Jetty, Tomcat, and Undertow. They did so for application's launched using JarLauncher or WarLauncher but did not consider application's launched in an IDE or using spring-boot:run in Maven or bootRun in Gradle. Running in an IDE or via Maven or Gradle introduces two new resource locations: - Jars on the classpath with file protocol URLs (they are always jar protocol URLs when using either launcher) - Directories on the classpath from a project that is depended upon and contains resources in META-INF/resources This commit updates the factories for all three containers to handle these new resources locations. The integration tests have also been updated.
Just wondering, where should I put static resources when using embedded Undertow? I have created a jar file that contains these resources and this is working fine when unsing tomcat or jetty, but undertow does not find the resources. |
As long as you're using the latest version of 1.4.x and 1.5.x, it should work the same way in all three embedded containers. If you've found a situation where that's not the case, please open a new issue with a small sample that reproduces the problem. |
I am using 1.5.2 and tomcat and jetty is working fine, but not undertow. All I do to switch, is change this dependency: compile("org.springframework.boot:spring-boot-starter-jetty") to either starter.tomcat or starter.undertow.. |
Seems like this is related to JSF, more specific Primefaces and their themes. Does this help or do you still need me to open a new issue with a sample case? |
If you'd like us to investigate, we'll need a new issue with a sample case please. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Will do, sorry and thanks! |
The behaviour of embedded Tomcat, Jetty, and Undertow is inconsistent when the containers themselves are dealing with static resources, i.e. when Spring MVC's resource handling isn't involved. For example, support for loading resources from
META-INF/resources
of nested jars works with Tomcat but doesn't work with Undertow. Furthermore, I believe it only works with Tomcat when Jasper's on the classpath.The text was updated successfully, but these errors were encountered: