DevTools deliberately throws an uncaught exception on the main thread
as a safe way of causing it to stop processing. This exception is
caught and swallowed by an uncaught exception handler. Unfortunately,
this has the unwanted side-effect of causing the JVM to exit with 1
once all running threads are daemons.
Normally, this isn't a problem. Non-daemon threads, such as those
started by an embedded servlet container, will keep the JVM alive and
restarts of the application context will occur when the user makes to
their application. However, if the user adds DevTools to an
application that doesn't start any non-daemon threads, i.e. it starts,
runs, and then exits, it will exit with 1. This causes both
bootRun in Gradle and spring-boot:run in Maven to report that the
build has failed. While there's no benefit to using DevTools with an
application that behaves in this way, the side-effect of causing the
JVM to exit with 1 is unwanted.
This commit address the problem by updating the uncaught exception
handler to call System.exit(0) if the JVM is going to exit as a
result of the uncaught exception causing the main thread to die. In
other words, if the main thread was the only non-daemon thread, its
death as a result of the uncaught exception will now cause the JVM
to exit with 1 rather than 0. If there are other non-daemon threads
that will keep the JVM alive, the behaviour is unchanged.
Closes gh-5968
Previously, when `spring.mvc.locale` was specified, that locale was used
regardless of the client's preferences. This commit adds an extra
`spring.mvc.locale-resolver` property that can control how the locale is
resolved. The default is `ACCEPT_HEADER` but can be set to `FIXED` to
restore the previous behaviour.
Closes gh-6083
This commit removes HSQLDB dependency from Batch Starter as most apps
that use Spring Batch will prefer to use a RDBMS of their choice to store
batch metadata.
Additionally, explicit spring-jdbc dependency has been replaced with JDBC
Starter dependency.
See gh-6081
Jetty 9.3 no longer has a jetty-jsap artifact and dependency
management for it was removed in ff602e6. It was inadvertently
reintroducved in b303b3f. This commit removes it again.
See gh-5290
See gh-5825
The JVM only allows URL.setURLStreamHandlerFactory to be called once.
This is problematic as the JSP support in embedded Tomcat and embedded
Jetty both call this method.
This commit uses reflection to null out URL’s factory field before and
after the embedded Jetty tests have run. This ensures that they can
run successfully if Tomcat has already installed its factory and that
Tomcat-related tests can also run afterwards.
See gh-5290
Previously, Spring Data Redis assumed that the class loader that loaded
its classes would also be able to load the application’s classes. This
assumption is faulty when there are multiple class loaders involved
such as when using dev tools or when Spring Data Redis is installed as
a shared library in a servlet container.
DATAREDIS-427 and DATAREDIS-501 removed this assumption by making the
default serialiser use the bean class loader. DevTools configures this
class loader to be the restart class loader which can load the
application’s classes. As a result of moving to Hopper SR2 snapshots,
these fixes are now available and we can remove our custom serialised.
Closes gh-5760
As of Spring Framework 4.3, spring-aop now embeds the classes from the
aopalliance:aopalliance jar. This means that the transitive dependency
on aopalliance:aopalliance is redundant and it can be excluded.
Closes gh-6159
In fact the folder was already created if the app is running as
a different user, but not if running as the current user, so it
was just a question of moving one line out of an if block.
Fixes gh-5986