When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
Refactor `spring-boot-loader` to reduce the amount of memory required
to load fat & exploded jars. Jar files now no longer store a full list
of entry data records, but instead use an array of entry name hashes.
Since ClassLoaders often ask each JAR if they contain a particular
entry (and mostly they do not), the hash array provides a quick way to
deal with misses. Only when a hash does exist is data actually loaded
from the underlying file.
In addition to the JarFile changes, the Archive abstraction has also
been updated to reduce memory consumption.
See gh-4882
PropertiesLauncher creates a ClassLoader that is used by the Launcher
to load an application’s classes. During the creation of this
ClassLoader URLs from its ClassLoader. This resulted resulting in Java
agents that are added to the system class loader via the -javaagent
launch option being available on both the system class loader and the
created class loader. Java agents are intended to always be loaded by
the system class loader. Making them available on another class loader
breaks this model.
This is the same problem that was in ExecutableArchiveLauncher and
that was fixed in ee08667e (see gh-863).
This commit updates PropertiesLauncher so that it skips the URLs of
any Java agents (found by examining the JVM’s input arguments) when
copying URLs over to the new ClassLoader, thereby ensuring that Java
agents are only ever loaded by the system class loader.
Closes gh-4911
Previously, JarFileArchive would always unpack any entries marked for
unpacking to ${java.io.tmpdir}/spring-boot-libs. This could cause
problems if multiple Spring Boot applications were running on the same
host:
- If the apps are run as different users the first application would
create the spring-boot-libs directory and the second and subsequent
applications may not have write permissions to that directory
- Multiple apps may overwrite each others unpacked libs. At best this
will mean one copy of a jar is overwritten with another identical
copy. At worst the jars may have different contents so that some of
the contents of the original jar disappear unexpectedly.
This commit updates JarFileArchive to use an application-specific
location when unpacking libs. A directory beneath ${java.io.tmpdir} is
still used but it's now named <jar-file-name>-spring-boot-libs-<uuid>.
A loop, limited to 1000 attempts, is used to avoid problems caused by
the uuid clashing.
Closes gh-4124
I think this is safe, judging by the integration tests, but I'm not
putting it in 1.2.x until we've had some feedback on it. The
integration tests actually had a bug that was masking this problem
because they were merging Properties from the whole classpath instead
of picking the first available resource (which is generally what
we do in Spring Boot applications for application.properties for
instance).
Fixes gh-3048
The format is rather unusual.
The time is 16 bits: 5 bits for the hour, 6 bits for the minutes, and 5
bits for the seconds. 5 bits only allows 32 values (0-31) so the number
must be doubled, meaning that the time is only accurate to the nearest
two seconds. Also, the JDK rounds this down by subtracting one. The
doubling and rounding is performed by shifting one place to the left
and masking off the right-most bit respectively.
The date is 16 bits: 7 bits for the year, 4 bits for the month, and 5
bits for the day. The year is from 1980, i.e. the earliest date that
can be represented is 1980-01-01.
See http://mindprod.com/jgloss/zip.html for more details of the format.
Fixes gh-2826
Previously, WarLauncher included its root on the classpath. It also used
a filtered version of its root archive to hide both the WEB-INF and
META-INF directories. This meant that files in WEB-INF and META-INF
could be found by the classloader (as they were on the classpath) but
could not be read as the filtered archive was hiding them.
This commit updates WarLauncher to remove the root of the war file from
the classpath. It also removes the filtering of the archive, thereby
allowing files in META-INF and WEB-INF to be accessed via the
ServletContext.
Closes gh-1792
* Windows: allow absolute file paths without file:/// prefix
* All: only add nested archives (not directories), so loader.path=lib/*
behaves the same as -classpath=lib/* (except for adding zip files)
Fixes gh-1352
The ExplodedArchive would erroneously always attempt to filter
its contents (and thereby shield them from a classloader that wrapped
it) even if they haven't been explicitly provided.
See gh-1352
Fix 'fat jar' support for windows to correctly deal with URL and path
slash issues. The root cause of the original problem was caused by JAR
URLs not including a root slash (ie `file:C:/Users` vs `file:/C:/Users`)
Fixes gh-1145
Update the executable JAR code to automatically unpack any entries
which include an entry comment starting `UNPACK:` to the temp folder.
The existing Maven and Gradle plugins have been updated with new
configuration options and the `spring-boot-tools` project has been
updated to write the appropriate entry comment based on a flag passed
in via the `Library` class.
This support has been added to allow libraries such a JRuby (which
assumes that `jruby-complete.jar` is always accessible as file) to work
with Spring Boot executable jars.
Fixes gh-1070
Update JarURLConnection to allow the resolution of items within a nested
jar, even if the jarFile passed to the connection is several levels up.
This prevent a connection from incorrectly resolving an entry against
the wrong jar file.
See gh-1070
Update `spring-boot-loader` ZIP processing code to support prefixed
bytes within the fat jar. This technique allows a bash script to be
embedded at the start of the JAR whilst still allowing `java -jar`
execution.
Fixes gh-1073
ExecutableArchiveLauncher creates a ClassLoader that is used by the
Launcher to load an application’s classes. During the creation of this
ClassLoader URLs from another ClassLoader are copied over. This was
resulting in Java agents that are added to the system class loader
via the -javaagent launch option being available on both the system
class loader and the created class loader. Java agents are intended to
always be loaded by the system class loader. Making them available on
another class loader breaks this model.
This commit updates ExecutableArchiveLauncher so that it skips the URLs
of any Java agents (found by examining the JVM’s input arguments) when
copying URLs over to the new classloader, thereby ensuring that Java
agents are only ever loaded by the system class loader.
Fixes#863
The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).
(Cherry picked from commit 06e364a9ff)
Fixes gh-764
The problem all along has been in AsciiBytes, so the fix in
commit ce3aaf was just a stop gap for a system where multi-byte
characters are supported but the default encoding is not UTF-8 (e.g.
most Windows systems). The real solution is not to leave it to
chance and always pick an encoding for the JarEntry names (i.e.
in AsciiBytes).
Fixes gh-764
