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
In Spring Boot 1.3.1 the class 'org.apache.logging.log4j.LogManager'
is used to check which logging backend is in use. But this class is
part of the log4j-api.jar and not part of the log4j-core.jar.
That means the check is invalid, as it does not detect the actual
core implementation of Log4j2 correctly.
When you want to redirect Log4j2 logging via SLF4J, a NPE occurs
each time the application is reloaded by the devtools, because the
class Log4j2RestartListener tries to shutdown Log4j2 resources.
This is done by accessing some internal shutdown method via
reflection. The method that is being looked for does not exist
when the log4j-api.jar is available only on the classpath,
resulting in a NPE. This causes the application to stop,
disappearing from the Spring Boot Dashboard in Eclipse
Closes gh-4831
Issue #4533 was supposed to make BasicBatchConfigurer public again but
unfortunately only the class visibility was changed. This commit makes
sure it can be overridden.
Closes gh-4888
Previously, the worker used non-daemon threads which meant that they
prevented the JVM from shutting down. Ideally, we’d avoid this problem
by closing the worker and access log receiver as part of stopping
Undertow, however, due to an apparent bug in Undertow [1], it’s not
possible to do so cleanly.
This commit configures the access log worker to use daemon threads so
that they do not prevent the JVM from shutting down. Unfortunately,
this means that the threads will still be running after the context has
been closed but before the JVM shuts down but that appears to be
unavoidable due to the aforementioned Undertow bug.
Closes gh-4793
[1] https://issues.jboss.org/browse/UNDERTOW-597
Andy Wilkinson
Phillip Webb
Stephane Nicoll
mrumpf
zhanhb
Kazuki Shimizu
Dave Syer
Johannes Edmeier
Johnny Lim
Spring Buildmaster