HotSwapAgent is an open source competition to JRebel. This commit adds
"org.hotswap.agent.HotswapAgent" to the list of known Java agent based
class reloaders. This causes same behavior as when JRebel is used: a full
restart is NOT triggered when any class changes, however LiveReload event
is still triggered.
See gh-8683
Separate logging ApplicationListeners classes to a different package
so that the root `logging` package is no longer aware of `context`
concerns.
Fixes gh-8611
Previously, reflection was used to set the OBJENESIS field of
DummyInvocationUtils with an Objenesis instance that does not use
caching. This has stopped working as the field is now declared final.
This commit updates the approach take by HateoasObjenesisCacheDisabler
to disable Objenesis's cache. Rather than changing the value of the
OBJENESIS field on DummyInvocationUtils, the cache field on the
ObjenesisStd instance is set to null instead. This has the desired
effect of disabling Objenesis's caching.
See gh-3784
Closes gh-8335
This commit refactors the `ServerProperties` property keys and
introduces a separate "server.servlet" namespace to isolate
servlet-specific properties from the rest.
Closes gh-8066
This commit removes `ServerProperties` and `ManagementServerProperties`
auto-configurations. Those properties objects are now created using
`@EnableConfigurationProperties` only.
Closes gh-8108
This commit provides auto-configuration for the Reactor Core 3 library.
A new configuration namespace, "spring.reactor" allows to configure
hooks on operators, like "spring.reactor.stacktrace-mode.enabled".
This property is enabled automatically by devtools, since it improves
the developer experience and provides full stacktrace information when
exceptions occur (but at a performance cost).
Fixes gh-7302
Previously, when DevTools' was used it would set the application
context's ResourceLoader and overwrite any custom ResourceLoader that
had been configured. On the rare occasion when the user had customized
the ResourceLoader this meant that the customization was lost and
certain resources would become unavailable.
This commit updates DevTools' ResourceLoader to delegate a custom
ResourceLoader if one has been configured. If one has not been
configured it delegates as before, i.e. to
WebApplicationContextResourceLoader for web applications and to
DefaultResourceLoader for all others apps.
Closes gh-8010
Update ClassLoaderFilesResourcePatternResolver to support servlet
resources when it's being used with a WebApplicationContext.
Prior to commit 918e122ddc a `ResourceLoader` was not added to the
`ApplicationContext`, meaning that servlet resources could be found by
virtue of the protected `getResourceByPath()` method. Following commit
918e122ddc, the context `ResourceLoader` is set, meaning that all calls
to `getResource` delegate to the `ResourceLoader` and the
`ApplicationContext` methods are not invoked. Since the devtools
`ResourceLoader` wasn't Servlet aware, servlet resources could not
be found.
Fixes gh-7752
Update LiveReloadServer so that different synchronization blocks are
used for the sockets and connection lists. Prior to this commit calling
`LiveReloadServer.stop()` would always result in a 60 second delay since
`stop()` owned the monitor add `removeConnection()` (called from a
different thread) needs it to remove the active connection.
Fixes gh-7749
Previously, remote DevTools only correctly supported modifying
existing classes. New classes that were added would be missed, and
deleted classes could cause a failure as they would be found by
component scanning but hidden by RestartClassLoader.
This commit introduces a DevTools-specific ResourcePatternResolver
that is installed as the application context's resource loader. This
custom resolver is aware of the files that have been added and
deleted and modifies the result returned from getResource and
getResources accordingly.
New intergration tests have been introduced to verify DevTools'
behaviour. The tests cover four scenarios:
- Adding a new controller
- Removing an existing controller
- Adding a request mapping to a controller
- Removing a request mapping from a controller
These four scenarios are tested with:
- DevTools updating a local application
- DevTools updating a remote application packaged in a jar file
- DevTools updating a remote application that's been exploded
Closes gh-7379
If the resource chain is used, such as by using the
`"spring.resources.chain.strategy.content.enabled"` property,
resource chain caching can prevent the developer from seeing
changes made to resources, so that caching should be disabled
when DevTools is enabled.
This commit sets the `"spring.resources.chain.cache"` property
to `true` when devtools is enabled.
Update `DevToolsPropertyDefaultsPostProcessor` so that property defaults
are only added at development time. Properties are now added only when
`Restarter` is initialize or remote devtools is enabled.
Fixes gh-7014
This commit switches off the auto-configured JspServlet's
development mode by default. Development mode is then switched on
when DevTools is on the class path.
Closes gh-7039
Prior to this commit any application configured to write
`META-INF/build-info.properties` could trigger unexpected application
restarts. The problem is particularly prevalent when using Eclipse M2E in
combination with Maven's `spring-boot-maven-plugin` `build-info` goal
and Gradle's `springBoot` `buildInfo()`.
Closes gh-7002
This commit enables compatibility build against Spring Framework 5.
The Velocity and Guava support that are deprecated in the 1.x line have
been removed and few other classes contain minor change to comply to non
backward compatible changes in Spring Framework 5.
This commit also switches the required java version to 8.
Closes gh-6977
Where possible, code that previously synchronized on this (or on the
class in the case of static methods) has been updated to use an
internal monitor object instead. This allows the locking model that's
employed to be an implementation detail rather than part of the
class's API.
Classes that override a synchronized method continue to declare
the overriding method as synchronized. This ensures that locking
is consistent across the superclass and its subclass.
Closes gh-6262
Previously, if an exception was resolved by a `HandlerExceptionResolver`
nothing the log indicated a failure to process the query.
This commit adds a new property `spring.mvc.log-resolved-exception` that
enables warning logs for supported `HandlerExceptionResolver` instances.
When Devtools is enabled, this flag is enabled by default.
Closes gh-2176
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, 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
Madhura Bhave
dreis
Stephane Nicoll
Bretislav Wajtr
Andy Wilkinson
Phillip Webb
Brian Clozel
Johnny Lim
Eddú Meléndez
Hrishikesh Joshi
Oscar Utbult
Marius Bogoevici
Craig Andrews
Martin Lippert