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
- Limit shared state between FileSystemWatcher and the watching thread
- Use a private monitor rather than synchronizing on this
- Use a Runnable implementation rather than subclassing Thread
- Synchronize consistently when reading and writing state
Closes gh-6039
The list of changes is written to on one thread and read from on
another. Without some form of sychronization this is not thread-safe.
This commit makes changes a synchronized list which should guarantee
that the reading thread can see the changes made by the writing thread.
It also removes a redundant call to clear the list of changes at the
start of waitsForPollingInterval.
See gh-6038
Previously, there were two problems with DevTools’ DataSource
auto-configuration:
1. It did not tolerate a context with multiple DataSources
2. It would attempt to shut down a DataSource that had not been created
by DataSourceAutoConfiguration and, therefore, where we could not be
sure of its configuration.
This commit updates DevToolsDataSourceAutoConfiguration so that it backs
off unless the context contains DataSourceProperties and a single
DataSource created by DataSourceAutoConfiguration. This ensures that it
can safely use DataSourceProperties to get the DataSource’s
driver class name and accurately determine if it’s an in-memory or
external database. Shutdown is only called for an in-memory database.
Closes gh-5540
5e0ba6ea added support for reading a jar manifest's Class-Path
attribute when resolving changeable URLs from a URLClassLoader,
however it did not handle relative URLs, i.e. URLs without a protocol,
correctly.
This commit updates ChangeableUrls so that it uses the URL of the
JAR that contains the manifest as the base for any new URLs that
are created. When the Class-Path entry is relative, this base will
be used. When the Class-Path entry is absolutee, URL's constructor
will ignore the supplied base.
Closes gh-5665
To overcome command length limits on Windows, IntelliJ IDEA may launch
an application with a single jar on the classpath that contains that
application's actual classpath in the Class-Path attribute of its
manifest. This would prevent DevTools restarts from working as it
only considered the single jar's URL when identifying changeable URLs
and ignored the URLs added to the classpath via the jar's manifest.
This commit updates ChangeableUrls when it is created from a
URLClassLoader to consider the Class-Path manifest attribute of any
jars in the class loader's URLs. This allows the full classpath to
be considered when identifying URLs that are changeable and that
need to be monitored for restart triggering.
Closes gh-5127
Shutdown handling has been improved so that it will run after any
EntityManagerFactory beans have been closed. This ensures that Hibernate
can, if configured to do so, drop its schema during restart processing.
Without this change, a benign exception could be logged if the database
was shutdown before Hibernate.
Closes gh-5305
Previously, if DataSourceAutoConfiguration had been explicitly excluded,
DevToolsDataSourceAutoConfiguration would cause refresh to fail due to
a missing DataSourceProperties bean. This commit corrects the condition
so that the auto-configuration is conditional on a DataSource bean and
a DataSourceProperties bean rather than only being conditional on one or
the other.
Closes gh-5269
Previously, if an application had been started without remote
debugging enabled, an attempt to connect to it via
RemoteSpringApplication and the HTTP tunnel would result in the
application being hammered by connection attempts for 30 seconds.
This commit updates the tunnel server to respond with Service
Unavailable (503) when a connection attempt is made and the JVM
does not have remote debugging enabled. When the client receives a
503 response, it now logs a warning message describing the possible
problem before closing the connection.
The client has also been updated to provide improved diagnostics when
a connection to the tunnel server cannot be established, for example
because the remote URL is incorrect, or the remote application isn't
running.
Lastly, the client has been updated so that it continues to accept
connections when a connection to the server is closed. This allows
the user to correct a problem with the remote application, such as
restarting it with remote debugging enabled, without having to also
restart the process that's running RemoteSpringApplication.
Closes gh-5021
Previously an in-memory database that wasn’t pooled (an
EmbeddedDatabase) would be shutdown when the context restarted, but
an in-memory database wrapped in a connection pool was not. This meant
that the former would be be wiped clean after each restart, whereas the
latter would not. In addition to being inconsistent, this also
caused problems with schema.sql and data.sql scripts when using
DevTools. If you were using an in-memory database wrapped in a
connection pool, a failure may occur during a restart as the scripts
were not being run against in clean database.
This commit adds an auto-configured bean to DevTools that, when the
context is being closed, will execute “SHUTDOWN” if it identifies that
the DataSource is not an EmbeddedDatabase and is for an in-memory
database.
Closes gh-4699
Previously, when Spring Session 1.1.0.M1 and DevTools were declared as
dependencies the application failed to start, because
sessionRedisTemplate could not be resolved.
This commit relaxes the dependency for sessionRedisTemplate in
restartCompatibleRedisSerializerConfigurer from
RedisTemplate<String, ExpiringSession> to RedisTemplate<?, ?> and uses
the bean name in a @Qualifer to ensure that the right RedisTemplate
bean gets injected.
Fixes gh-4895
Closes gh-4896
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
Previously, ServerThread would check for a disconnect as soon as it
had been started. This raced with it handling its first connection. If
the check for disconnect won the race it would incorrectly determine
that the disconnect timeout had been reached and wouldn’t respond to
the connection.
This commit updates ServerThread so that it only checks the disconnect
timeout once it’s handled at least one connection.
Closes gh-4668
Previously, when a session attribute that had been stored in Redis was
being deserialized, the app class loader would be used. This would
result in a ClassCastException if the attribute was an instance of a
class visible to the restart class loader.
This commit auto-configures Spring Session’s RedisTemplate to use a
custom deserializer that uses the restart class loader when
deserializing session attributes.
Closes gh-3805
Previously, ServerThread.lastHttpRequestTime was written while
synchronized on this.httpConnections but was read without
synchronization. This could lead to a read of the field producing the
wrong value and cause premature connection timeout.
This commit moves the call to checkNotDisconnected into a block that
sychronizes on this.httpConnections, thereby ensuring that
lastHttpRequestTime can be read safely.
Closes gh-4668
Allow `META-INF/spring-devtools.properties` files to be used by
application developers to declare is specific jars should be included
or excluded from the RestartClassLoader.
A typical example where this might be used is a company that develops
it's own set of internal JARs that are used by developers but not
usually imported into their IDE.
See gh-3316
