Previous fix for handling wildcard entries in a classpath
imposed a new problem in a case where entry is a directory
with a jar files but also contains a lot of nested directories.
For example entry "./*" resulted for scanning whole disk starting
from "/". In case of default hadoop classpath, it scanned everything
under hadoop's installation. On some cases this deep scan was hidden
and was revealed by NPE's for file access exceptions.
When we want to support wildcard entries we only want to get
jar files from that directory, while boot itself have a need
to travel recursively to find classfiles from an expoded archive.
We handle this case by using recursive(true by default) flag in
ExplodedArchive and this flag is set to false in PropertiesLauncher
if we match wildcard.
PropertiesLauncher now supports creating its own class loader
from looader.classLoader property. It will succeed if the
implementation specified has a default constructor or one
that takes a parent class loader, or one that takes a URL[]
and a parent class loader (like URLClassLoader).
Refactor spring-boot-loader to work directly with low level zip data
structures, removing the need to read every byte when the application
loads.
This change was initially driven by the desire to improve tab-completion
time when working with the Spring CLI tool. Local tests show CLI
startup time improving from ~0.7 to ~0.22 seconds.
Startup times for regular Spring Boot applications are also improved,
for example, the tomcat sample application now starts 0.5 seconds
faster.
By default it is on, but you can switch it
off (`-P '!integration'`) to ignore integration tests
and get a faster build.
.travis.yml uses this feature so that it doesn't keep
failing on a timeout.
Previously, Repackage would attempt to repackage every jar in the
project. This would cause it to incorrectly attempt to repackage source
and javadoc jars.
This commit updates Repackage so that it ignores any jar with a
classifier. Hopefully this is a reasonable approximation for ignoring
'special' jars that should not be repackaged such as sources and
javadoc.
Depending on ASM itself can cause problems as it can clash with other
libraries' dependency on it. This commit updates
spring-boot-loader-tools to depend upon spring-core and use its
repackaged copy of ASM instead. Depending on spring-core also brings
with it the advantage of giving access to its various bits of utility
code.
spring-boot-maven-plugin has been updated to remove its ASM
exclusions as they will no longer clash with the version from
spring-boot-loader-tools
(59483608)
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.
Dave Syer
Janne Valkealahti
Phillip Webb
Guo Du
Christian Dupuis
Andy Wilkinson
dave noel
Biju Kunjummen
Daniel L. Buchko
Phil Webb
Phillip Webb