Add a `NestedFileSystemProvider` implementation so that the JDK's
`ZipFileSystem` can load content from nested jars and nested
directory entries.
Creating a `ZipFileSystem` may be a relatively expensive operation as
zip structures need to be parsed and in the case of directory entries
a virtual datablock nees to be generated on the fly. As such, we
install the `ZipFileSystem` as late as possible since in a typical
application it may never be needed.
This commit also tweaks Gradle and Maven plugins to ensure that the
service loader file is written to repackaged jars.
Closes gh-7161
Update Gradle and Maven plugins to write an empty `META-INF/BOOT.SF`
file whenever there is a nested signed jar.
This update allows Oracle Java 17 to correctly verify the nested JARs.
The file is required because `JarVerifier` has code roughly equivalent
to:
if (!jarManifestNameChecked && SharedSecrets
.getJavaUtilZipFileAccess().getManifestName(jf, true) == null) {
throw new JarException("The JCE Provider " + jarURL.toString() +
" is not signed.");
}
The `SharedSecrets.getJavaUtilZipFileAccess().getManifestName(jf, true)`
call ends up in `ZipFile.getManifestName(onlyIfSignatureRelatedFiles)`
which is a private method that we cannot override in our `NestedJarFile`
subclass. By writing an empty `.SF` file we ensure that the `Manifest`
is always returned because there are always "signature related files".
Fixes gh-28837
Update `spring-boot-loader-tests` with a test that checks verified
BouncyCastle jars can be loaded. Currently the Oracle JDK only supports
verification if the jar is unpacked.
See gh-28837
Update `spring-boot-launch-script-tests` and `spring-boot-loader-tests`
so that JDK archives are now downloaded by Gradle and cached across
builds.
Closes gh-37450
Create alternative launcher classes under the package
`org.springframework.boot.loader.launch` and use them in favor
of the previous location.
This update is designed to improve compatibility with future
changes in the loader.
Closes gh-37667
Previously, when a Servlet-based WebServer was stopped it would also
stop the ServletContext. This led to problems as Tomcat and Undertow
would then not allow a restart. Jetty would allow a restart but
duplicate servlet registrations would then be attempted.
This commit modifies the WebServer lifecycle to separate stopping
and destruction for both servlet and reactive web servers. This
allows a WebServer's stop() implementation to leave some components
running so that they can be restarted. To completely shut down a
WebServer destroy() must now be called.
Both Tomcat and Jetty WebServers have been updated to stop their
network connections when stop() is called but leave other components
running. This works with both servlet and reactive web servers.
Note that an Undertow-based Servlet web server does not support
stop and restart. Once stopped, a Servlet Deployment cannot be
restarted and it does not appear to be possible to separate the
lifecycle of its network connections and a Servlet deployment.
Reactor Netty and Undertow-based reactive web servers can now also
be stopped and then restarted. Calling stop() stops the whole server
but this does not cause a problem as there's no (application-exposed)
ServletContext involved. There may be room to optimize this in the
future if the need arises.
Closes gh-34955
This commit adds a `Build-Jdk-Spec` attribute to the manifest in a
jar or war file built with the Spring Boot Gradle plugin. This
aligns the Gradle plugin's behavior with the default Maven plugin
behavior.
This removes the need to set a `BP_JVM_VERSION` environment variable
when invoking Cloud Native Buildpacks, as the Paketo buildpacks will
honor `Build-Jdk-Spec` in a jar or war manifest to determine the
default JVM version.
Fixes gh-32829
This commit migrates our remaining usage of the httpclient 4.x to use
instead httpclient5, now that the 4.x support has been removed in
`RestTemplate`.
Closes gh-32461
As htttpclient 4.x is not supported anymore by `RestTemplate`, this
commit changes such dependencies to httpclient5 instead. In some cases,
the httpclient 4.x was transitively brought by a non-Spring dependency.
See gh-32461
This commit adds the `AutoConfigurationImportsAnnotationProcessor` to
the `spring-boot-autoconfigure-processor` annotation processor
module. When added to a project build, the annotation processor will
generate the
`org.springframework.boot.autoconfigure.AutoConfiguration.imports`
file automatically from `@AutoConfiguration`-annotated classes. It
also applies the annotation processor to the Spring Boot build.
Closes gh-31228
Scott Frederick
Andy Wilkinson
Phillip Webb
Phillip Webb
Moritz Halbritter
Andy Wilkinson
Scott Frederick
Krzysztof Krason
Brian Clozel
Johnny Lim
Stephane Nicoll