Prior to this commit, the Aether-based GrapeEngine was loaded in the
same class loader as the rest of Boot. This led to Aether's and its
dependencies' types polluting the application's class path. Most
notably, this caused problems with logging as the logging framework
could be permaturely initialized.
This commit isolates AetherGrapeEngine, Aether and its dependencies
into a separate class loader. This is done by customizing the
packaging of the CLI's jar file with the internal directory housing
all of the types that will be loaded by the separate class loader.
The Git plugin was primarily being used to provide version information
that Boot's maven plugin can add into the MANIFEST.MF of the uber-jars
that it creates under the Spring-Boot-Commit-Id attribute.
This commit removes the Git plugin from Boot's own projects, but
leaves it in the spring-boot-starter-parent for use by Spring
Boot-based applications.
The attribute in the uber-jars' MANIFEST.MF has been replaced with a
Spring-Boot-Version attribute. The value of this attribute is the
implementation version of Repackager class's package.
Fix RandomAccessJarFile to correctly read certificate information as
jar entries are loaded. This change allows signed nested jars to be
used as JCE providers.
To use PropertiesLauncher instead of JarLauncher in an
executable JAR we have provided tooling support. In Maven
(using the starter parent to default some of the settings):
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>ZIP</layout>
</configuration>
</plugin>
in Gradle:
apply plugin: "spring-boot"
springBoot {
layout = 'ZIP'
}
}
[Fixes#58837492] [bs-330] Add tooling for PropertiesLauncher
PropertiesLauncher can now be used to run an executable jar, and by
default it will pick up nested archives in lib/ (where the Boot
tools puts them). User can provide loader.path (colon-separated)
to change the nested path.
[#58837492] [bs-330] Add tooling for PropertiesLauncher
...otherwise you can see cryptic NoClassDefFound errors
because the application class was loaded from the parent
on the file system, but then it doesn't have access to the
child loaders nested jars.
Fix LaunchedURLClassLoader to only enumerate resources from the
rootLoader and the URLs.
Commit cd2c189 (Support javaagent instrumentation with loader) added
a parent classloader and used filtering in the loadClass() method
to ensure classes were loaded from the appropriate location. The change
in parent means that locally packaged resources are found twice, once
from the parent, and once from the self archive URL.
LaunchedURLClassLoader now overrides getResource and getResources to
filter out the parent classloader and instead only add resources from
the root classloader and the URLs.
Issue: #56232870
Refine the loading order of LaunchedURLClassLoader to consider the
root loader before locally bundled classes.
The prevents classes from locally bundled JARs from replacing system
classes.
Issue: #56232870
Update spring-boot-loader to allow `-javaagent` instrumentation when
running from executable jars.
Prior to this commit the `Launcher` skipped the application classloader
and instead used the system classloader as a parent. This was to ensure
that locally packaged classes were always loaded by the classloader
that had access to nested jars. Unfortunately when using the
`-javaagent` option, it is the application classloader that is modified.
The `Launcher` class now uses the application classloader as parent
and `LaunchedURLClassLoader` has been updated to always search local
URLs before delegating to the parent. This is very similar to the way
that most application servers handle the loading of war files.
Issue: #56232870
Provide accurate InputStream.available() results by using the size
attribute of the ZipEntry. This helps improve performance with
CGLib and also fixes issues where libraries expect that a non-zero
result from available() indicates that read() will not return -1.
Update RunMojo to include an @Execute annotation. Allows the use of
`mvn spring-boot:run` without having to compile/package first. Now a
command like `mvn clean spring-boot:run` works.
The phase for @Execute annotation is along the lines of what is used
for the `jetty:run` plugin.
Rework main build POM to be an aggregator pom that does not inherit
from any parent. Introduce new spring-boot-dependencies module to
act as a parent for both spring-boot-starter-parent and
spring-boot-parent.
Andy Wilkinson
Phillip Webb
Dave Syer
dave noel
Biju Kunjummen
Daniel L. Buchko
Phil Webb
Phillip Webb