Previously, jars (either top-level or nested) in Zip64 format were
treated as normal jar files. This would lead to a failure later on
when an attempt was made to read an entry from the file.
This commit updates the loader to fail fast when it encounters a
Zip64 jar file. Such files are identified by the number of entries
in the central directory end record being 0xFFFF.
Closes gh-8735
Previously, WelcomePageHandlerMapping would forward to index.html.
This assumed that the static path pattern was always /**. If it had
been customised to, for example, /foo/**, then the forward would still
be to index.html and a 404 would result as the page is actually
available at /foo/index.html.
At first glance, it would appear that the forward should be made to
foo/index.html. However, as it's a forward rather than a redirect,
any relative URLs in the index.html page would then be resolved using
/ whereas they should be resolved using /foo/. This could be addressed
by using a redirect rather than a forward, but we don't want to do
that as it's more invasive and would require a roundtrip back to the
client. Instead, this commit simply stops performing the forward when
the static path pattern is not /**.
Closes gh-8788
This commit makes sure that if a `javax.cache.CacheManager` is required,
an auto-configured `HazelcastInstance` is fully resolved first. This
prevents the case where the JCache bootstrap actually starts an instance
early, followed by a second (potentially unwanted) instance created by the
regular auto-configuration.
Since the JCache implementation works with an `HazelcastInstance` behind
the scenes, if there is one `HazelcastInstance` configured and it has a
name, then we configure the `CacheProvider` to use that. Future Hazelcast
version will allow to pass the instance directly (i.e. not requiring an
actual name).
Closes gh-8484
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.
