Fix JarEntryData to re-read the local header, rather than relying on
the central directory record.
This protects against the situation where a JAR file is written with an
'Extra Field Length' that is different in the local header to the
central directory header.
This appears to be the case with aspectj 1.7.4 which contains the
following central directory file header for ProceedingJoinPoint:
50 4B 01 02 signature
14 03 version made by
0A 00 version required
00 00 general
08 00 compress methods
0E 40 59 43 last modified
2D 59 20 70 crc
EC 00 00 00 csize
8D 01 00 00 size
2A 00 fname len
00 00 ext field len
00 00 file comment len
00 00 disk num
00 00 int file att
00 00 A4 81 ext file att
97 F3 00 00 relative offset of the local file header
... file name
and the following local header:
50 4B 03 04 signature
0A 00 version required
00 00 general
08 00 compress method
0E 40 59 43 last modified
2D 59 20 70 crc
EC 00 00 00 csize
8D 01 00 00 size
2A 00 fname len
14 00 ext field len
... file name
... extra field
Note that the 'ext field len' is 0x00 in the central record but 0x14 in
the local record.
Fixes gh-203
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.
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
Phillip Webb
Dave Syer
Janne Valkealahti
Guo Du
Andy Wilkinson