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
Previously, the Launcher was creating a new runner thread that would
call the application's main method. An exception thrown by this thread
is handled differently to one thrown by the JVM's main thread leading
to different exit behaviour. Furthermore, the separate thread isn't
actually necessary.
This commit removew the use of a separate runner thread from the
Launcher. This means that the JVM's exit behaviour will be consistent
and also removes the overhead of createing a starting an extra thread.
Closes gh-5006
Ensure that JarFile caches are cleared once the ApplicationContext has
loaded. Caches are cleared manually with the assumption that no
further class loading is likely.
Closes gh-4882
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
Remove the use of JDK loggers in Launcher and PropertiesLauncher to
ensure allow the custom Log4j2 `LogManager` to be used with Spring Boot
applications.
Fixes gh-3815
Commit 5a1ee6eb added support for disabling use of start-stop-daemon
via a placeholder in the default launch script. Unfortunately, that
placeholder was subsequently broken in 81a47639.
This commit reinstates the placeholder and adds tests to verify that all
of the placeholders in the launch script can be replaced and that they
have the required default values. Furthermore, it also allows the use of
start-stop-daemon to be configured via USE_START_STOP_DAEMON in an
app’s .conf file. This allows the configuration to be changed after the
app has been built.
Closes gh-4985
Previously, if an application’s main method threw an exception,
MainMethodRunner would catch the exception and call System.exit(1).
This meant that the JVM would exit, irrespective of whether or not
any non-daemon threads were running. In contrast, when an application’s
main method was invoked directly (in an IDE, for example) the JVM
would not exit if one or more non-daemon threads were running. This
is standard JVM behaviour that we should be consistent with in the
launcher.
This commit updates MainMethodRunner to wrap any exception thrown by an
application’s main method in a RuntimeException and rethrow it. This
alllows the JVM to handle the exception and use its normal rules for
deciding whether or not it should exit.
Closes gh-4984
Generalize the `skip` property to start and stop goals so that one
can control if the Spring Boot app is starting via a configuration
property.
Note that this only controls the Spring Boot Maven plugin and the
failsafe maven plugin should be updated accordingly.
Closes gh-4922
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, the default launch script would send SIGTERM once and then
wait for up to 60 seconds for the app to have stopped. If the service
was stopped immediately after being started the first SIGTERM would
occasionally be ignored (presumably because the JVM was not yet in a
state to handle it) causing the service stop request to fail.
This commit updates the launch script to resend SIGTERM to the process
if it's still running 30 seconds after the first SIGTERM was sent.
Closes gh-4941
$arguments needs to be split on spaces so it can’t just be wrapped
in quotes. This commit updates arguments to be an array that is then
expanded ("{arguments[@]}"). The use of @ and double quotes means that
it is expanded into all elements individually quoted.
See gh-4866
This commit completes the changes to consistently used static final
fields for Log instances that were started in ec2f33f9. Specifically it:
- Removes this. when accessing logger fields that are now static
- Renames some fields from log to logger
- Makes some logger fields static
See gh-4784
81a4763 introduced a regression when multiple RUN_ARGS or JAVA_OPTS were
configured. Rather than the JVM being launched with multiple arguments
all of the RUN_ARGS or JAVA_OPTS were passed as a single argument. This
caused unexpected behaviour and typically caused the application to fail
to start.
This commit updates the quoting of the arguments the are supplied when
launching the app using start-stop-daemon so that space-separated
entries in RUN_ARGS and JAVA_OPTS remain separate.
Closes gh-4866
Previously, the launch script used which to determine the availability
of start-stop-daemon. which isn’t available by default on all OSs.
For example, it’s not available by default on CentOS 5.
This commit updates the launch script to use type when determining if
start-stop-daemon is available. This improves the portability of the
script and makes the use of type consistent throughout the script.
Closes gh-4925
Previously, the launch script would wait for the pid file to exist
before continuing. This didn’t work 100% of the time as it left a
window where the file had been created but the PID had not been written
to it that could result in an incorrect report of the app failing to
start.
This commit updates the script to wait for the file to have a size
greater than zero before continuing. This ensures that the pid has
been written to the file before the pid is read from the file and used
to check that the process is running.
Closes gh-4923
Update exit code support to allow the ExitCodeGenerator interface to
be placed on an Exception. Any uncaught exception implementing the
interface and returning a non `0` status will now trigger a System.exit
with the code.
Fixes gh-4803
Ensure that Collections.isEmpty() is used to check if there are no
elements in a collections. This is more explicit and can be faster than
calling .size().
Closes gh-4783
Exiting with 0 when cd fails is likely to be incorrectly interpreted
as success so we should exit with a non-zero value. Ideally, the init
script status action would exit with 4 but, at the point when
the cd is performed, we don’t even know if we’re running as an init
script. Exiting with 1 seems to be a reasonable compromise as it’s
fine for the non init-script case as well as being correct for all
init script actions other than status.
See gh-4653
Allow users to easily opt-opt of using the start-stop-daemon in the
launch script. This may be required on distros that include older
versions.
Fixes gh-4732
Replace all new-line characters in multi-line pom descriptions before
inserting into the launcher script. Prior to this commit the shell would
attempt to execut the extra lines, for example:
<description>
A multi-line pom description that could do something terrible:
rm -r foo
</description>
Closes gh-4703
Phillip Webb
Andy Wilkinson
Stephane Nicoll
Johnny Lim
Spring Buildmaster
Johannes Edmeier
Kirill Vlasov
Michitomo Nakahara
Robert Thornton
mnhock