Previously, DefaultResourceLoader instances were created using the
default constructor. This causes the resource loader to capture the
TCCL that was in place at that time. This can lead to a class loader
leak if the resource loader is referenced directly or indirectly from
a static field of a class loaded by a different class loader.
This commit updates the creation of DefaultResourceLoader instances
in main code so that the resource load will use the class loader of
the creating class. In almost all cases this will be the same class
loader as was the thread context class loader that was being captured
so the change in behavior is minimal. Crucially, it will still address
the situation where the TCCL was different.
Note the DevTools' ApplicationContextResourceLoader has been updated
to explicitly use the TCCL. This ensures that it uses the restart
class loader which is required for DevTools to function correctly.
Fixes gh-20900
Prior to this commit, default error responses included the message
from a handled exception. When the exception was a BindException, the
error responses could also include an errors attribute containing the
details of the binding failure. These details could leak information
about the application.
This commit removes the exception message and binding errors detail
from error responses by default, and introduces a
`server.error.include-details` property that can be used to cause
these details to be included in the response.
Fixes gh-20505
Previously, DevToolsDataSourceCondition called
getBeanNamesForType(Class) which could trigger unwanted initialization
of lazy init singletons and objects created by FactoryBeans.
This commit updates DevToolsDataSourceCondition to prohibit eager
init when getting the names of the beans of a particular type.
Fixes gh-20430
This commit changes uses of ClassLoader.loadClass to Class.forName for
consistency with what was initiated in #19342 and better compatibility
with GraalVM.
Closes gh-19824
This commit makes sure that any subsequent call on addProtocolResolver
on the context will impact the ResourceLoader implementation that
DevTools sets on the context.
This makes sure that any custom ProtocolResolver that is set later in
the lifecycle is taken into account.
Closes gh-17214
Meta-annotate `ClassPathExclusions` and `ClassPathOverrides` with
so that the `ModifiedClassPathExtension` no longer needs to be
used directly.
See gh-17491
Apply checkstyle rule to ensure that private and package private
classes do not have unnecessary public methods. Test classes have
also been unified as much as possible to use default scoped
inner-classes.
Closes gh-7316
Since the move to JUnit 5, a number of tests were failing on Windows.
The majority were failing due to open file handles preventing the
clean up of the tests' temporary directory. This commit addresses
these failures by updating the tests to close JarFiles, InputStreams,
OutputStreams etc.
A change has also been made to CachingOperationInvokerTests to make
a flakey test more robust. Due to System.currentTimeMillis() being
less precise on Windows than it is on *nix platforms, the test could
fail as it would not sleep for long enough for the TTL period to have
expired.
As of spring-projects/spring-hateoas#854, Spring HATEOAS is not relying
on Objenesis anymore and removed the cache that was being used for it.
This commit removes the support for clearing that cache when running an
application with Devtools enabled.
See gh-16833
This commit migrates `AnnotationConfigReactiveWebApplicationContext`
parent to the `GenericApplicationContext` abstraction. Any use of
`AnnotationConfigWebApplicationContext` is also removed as it also
inherits from the `AbstractRefreshableApplicationContext` outdated
hierarchy.
A new `AnnotationConfigServletWebApplicationContext` context is
introduced instead, extending from `GenericApplicationContext` and
providing the counter part of the reactive context for the Servlet-based
web app tests.
See gh-16096
Previously, DevTools would retry the upload of the changes to an
application in the event of a ConnectException. If a different
network-level failure occurred, it would not be retried and would
cause the file watching thread to die.
This commit attempts to make things more robust by retrying all
SocketExceptions and not just ConnectExceptions. A warning is
logged when a failure occurs. A separate debug message that
includes the exception is also logged.
Closes gh-10317
This covers the cases when:
* An Java agent based reloader (e.g. JRebel) is being used
* The reloader was disabled by using a system property
See gh-14807
Update `DevToolsPropertyDefaultsPostProcessor` to automatically set
the recently introduced `spring.messages.reloadable` property to
`true`.
Closes gh-14699