Might be related to: #7595 (or at least to a comment in this issue)
Starting with 1.4.3, our JSF application isn't processing JSF pages anymore.
I've appended a small example application. After started, call http://localhost:8085/index.xhtml.
BTW: If you start the application in Eclipse with the Spring Plugin, the result depends on your eclipse environment (for some developers it works, for some not - guess it depends, which loader is used by eclipse),
The change that has stopped this from working is intentional as it aligns Spring Boot more closely with the Servlet spec.
The spec states that resources in META-INF/resources should be loaded from jars packaged in WEB-INF/lib but should not be loaded from META-INF/resources within the main archive. In 1.4.2 and earlier (and only with Tomcat (see #8299)) we loaded resources from META-INF/resources within the main archive (actually from BOOT-INF/classes/META-INF/resources). In 1.4.3 and later we now only load resources from META-INF/resources of a jar packaged in BOOT-INF/lib.
The one significant difference between a jar and a war file is that a war project can use src/main/webapp to package resources in the root of the archive from where they will be accessible. This isn't an option with a jar. We can consider officially supporting BOOT-INF/classes/META-INF/resources as an extension to what the Servlet spec suggests, but I'm yet to convince myself that it's a good idea.
In the meantime, you have two options here:
src/main/webapp/ for your resources rather than src/main/resources/META-INF/resources/. You can still launch it using java -jar.BOOT-INF/libI'm going to close this in favour of #8299 which will make resource handling consistent across all three containers. We'll consider supporting BOOT-INF/classes/META-INF/resources as part of that.
On second thoughts, this would be better handled as a separate issue rather than rolling it into #8299
This is also the case for JSP pages. My Kerberos bases SSO solution stops working, when the Spring Boot Maven Plugin is later than 1.4.2.RELEASE
@GyllingSW JSPs are only supported when you package your application as a war file
@wilkinsona - I know JSP has limitations, but non the less it works with the maven plugin <= the 1.4.2.RELEASE version.
I use the approach shown here:
https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-web-jsp
@GyllingSW That sample is fine. It is building a war file. If you're doing that then there's no problem
I'm going to close this. There's been relatively little demand for it yet implementing it would add complexity to achieve something that can already been done using one of the two options that I described in my comment above.
Most helpful comment
The change that has stopped this from working is intentional as it aligns Spring Boot more closely with the Servlet spec.
The spec states that resources in
META-INF/resourcesshould be loaded from jars packaged inWEB-INF/libbut should not be loaded fromMETA-INF/resourceswithin the main archive. In 1.4.2 and earlier (and only with Tomcat (see #8299)) we loaded resources fromMETA-INF/resourceswithin the main archive (actually fromBOOT-INF/classes/META-INF/resources). In 1.4.3 and later we now only load resources fromMETA-INF/resourcesof a jar packaged inBOOT-INF/lib.The one significant difference between a jar and a war file is that a war project can use
src/main/webappto package resources in the root of the archive from where they will be accessible. This isn't an option with a jar. We can consider officially supportingBOOT-INF/classes/META-INF/resourcesas an extension to what the Servlet spec suggests, but I'm yet to convince myself that it's a good idea.In the meantime, you have two options here:
src/main/webapp/for your resources rather thansrc/main/resources/META-INF/resources/. You can still launch it usingjava -jar.BOOT-INF/libI'm going to close this in favour of #8299 which will make resource handling consistent across all three containers. We'll consider supporting
BOOT-INF/classes/META-INF/resourcesas part of that.