Previously, when deploying a Spring Boot application to a container,
the servlet context property source was not fully initialised until
the context was refreshed. This led to a problem where a value from a
property source with lower precedence would be seen during the early
stages of the application starting. Once the servlet context property
source had been initialized, its value for the property would then
become visible effectively making it appear as if the property's
value had changed during startup. This led to a specific problem
with determining active profiles.
If spring.profiles.active was set both in JNDI and via the servlet
context both profiles would end up being active, rather than the
more intuitive behaviour of the profiles made active via the servlet
context overriding those made active via JNDI.
This commit updates SpringBootServletInitializer so that it explicitly
creates the StandardServletEnvironment and initializes its property
sources using the servlet context. This is done before the application
is created and run, thereby ensuring that the servlet context
property source is available throughout the application's startup.
Closes gh-9972
This reverts commit bbca612a57.
StandardJarScanner, which contains the faulty assumption about
URLClassLoader is part of Jasper. Jetty, like Tomcat, uses Jasper for
JSPs so it's also affected.
See gh-10456
Previously, StaticResourceJars would only find jars with
META-INF/resources content if it had been loaded by a URLClassLoader.
This is not the case on Java 9 and, as a result, static content in
META-INF/resources of any jars on the class path was not found.
This commit updates StaticResourceJars to fall back to using the
JVM's class path to find static resource jars when it was loaded by
a ClassLoader that is not a URLClassLoader.
Closes gh-10455
Stephane Nicoll
Eddú Meléndez
Andy Wilkinson
Johnny Lim
Kedar Joshi
dreis2211
David Pavel
Phillip Webb
Madhura Bhave
jfarcand