When an application is run as an executable archive with nested jars,
the application's own classes need to be able to load classes from
within the nested jars. This means that the application's classes need
to be loaded by the same class loader as is used for the nested jars.
When an application is launched with java -jar the contents of the
jar are on the class path of the app class loader, which is the
parent of the LaunchedURLClassLoader that is used to load classes
from within the nested jars. If the root of the jar includes the
application's classes, they would be loaded by the app class loader
and, therefore, would not be able to load classes from within the
nested jars.
Previously, this problem was resolved by LaunchedURLClassLoader being
created with a copy of all of the app class laoder's URLs and by
using an unconventional delegation model that caused it to skip its
parent (the app class loader) and jump straight to its root class
loader. This ensured that the LaunchedURLClassLoader would load both
the application's own classes and those from within any nested jars.
Unfortunately, this unusual delegation model has proved to be
problematic. We have seen and worked around some problems with Java
Agents (see gh-4911 and gh-863), but there are others (see gh-4868)
that cannot be made to work with the current delegation model.
This commit reworks LaunchedURLClassLoader to use a conventional
delegate model with the app class loader as its parent. With this
change in place, the application's own classes need to be hidden
from the app class loader via some other means. This is now achieved
by packaging application classes in BOOT-INF/classes (and, for
symmetry, nested jars are now packaged in BOOT-INF/lib). Both the
JarLauncher and the PropertiesLauncher (which supports the executable
jar layout) have been updated to look for classes and nested jars in
these new locations.
Closes gh-4897
Fixes gh-4868
Previously, the DatabaseDriver enumeration contained entries for
some databases without having dependency management for the database
driver dependency. This leads to the possibility of a user inadvertently
using the wrong version of a driver where the class names do not match
those listed in the enumeration. A further problem is that we do not
test that the class names listed in the enumeration match the
names of Driver and XADataSource implementations in the database driver.
This commit completes the database driver dependency management so that
dependency management is provided for every driver that is both listed
in DatabaseDriver and available in Maven Central. It also adds tests
for DatabaseDriver that ensures that each class that is listed exists
and implements the required interface (java.sql.Driver or
javax.sql.XADataSource).
Closes gh-4946
When an app is deployed to Tomcat, all of the application's startup
is performed with a WebAppClassLoader being the thread context
class loader. When an app is using embedded Tomcat, the
WebAppClassLoader is created as part of the application starting but
is never set as the thread context class loader. This difference
in TCCL can cause problems. For example, it breaks the use of JNDI
during application startup with embedded Tomcat.
This commit updates the embedded Tomcat servlet container to set
the TCCL to be the WebAppClassLoader once the Tomcat context has
been started. Once Tomcat is stopped, it sets the TCCL back to the
ClassLoader that loaded it.
Closes gh-2308
We rarely use the same configuration in multiple test classes, but
Spring’s Test framework caches each context by default. For projects
with large numbers of integration tests, this can lead to tens of
contexts being cached. This increases memory usage, live thread count,
etc for no benefit.
This commit adds @DirtiesContext to the integration tests in
spring-boot, spring-boot-autoconfigure, and spring-boot-actuator so
that the context is closed once the test class has completed.
See gh-5141
Introduce configuration options for "spring.redis.cluster.nodes" and
"spring.redis.cluster.max-redirects". Properties such as "timeout" and
others remain available via "spring.redis.timeout" and do not have to be
configured on the cluster itself.
See gh-5128
The integration tests for the Spring Data Cassandra sample application
fail intermittently, apparently due to Cassandra failing to start
within the default timeout period of 10000ms.
In attempt to get the tests to pass reliably, this commit increases
the timeout to 60000ms (1 minute).
This commit adds a new key that configures a GzipResourceResolver
in the resource handling chain.
Configuring an application with the following will add that resolver,
which checks for gzipped resources in the configured locations:
```
spring.resources.chain.gzipped=true
```
This means that if a resource "style.css" is requested, the
GzipResourceResolver will look for resources named "style.css.gz", which
should be a gzipped variant of the "style.css" file. Note that this
resolver only checks for variants if the client supports the "gzip"
encoding, as defined in the "Accept-Encoding" HTTP request headers.
Fixes#4683
Previously, both Atomikos and Bitronix were bound on the `spring.jta`
namespace which makes very hard to figure out which property belong to
which implementation. Besides, `AtomikosProperties` only exposed public
setter which does not generate any useful meta-data.
This commit moves the external configuration for Atomikos and Bitronix to
`spring.jta.atomikos.properties` and `spring.jta.bitronix.properties`
respectively. It also improves the meta-data support for those two
namespaces.
Closes gh-5165
Spring Data Couchbase 2.0 sets the default consistency to "update-after"
which is good for performance reason but can be quite confusing. Since
the team has decided to switch to "read-your-own-writes" in 2.1, Spring
Boot already offers the improved default right now.
This commit exposes an additional property that can be used to change
the Couchbase's default consistency.
Closes gh-5159
Expose an `auto-index` property that controls if views and indexes
should be created automatically.
Update the sample so that it uses this new property, lowering the manual
steps to make it working on a vanilla couchbase server.
See gh-3498
Previously, if one wants to create a custom `JmsListenerContainerFactory`
or `RabbitListenerContainerFactory`, a bunch of code from the auto-
configuration must be duplicated.
This commit introduces two services to configure such factory for JMS
and AMQP with the same sensible defaults that were applied by the
auto-configufrations.
Closes gh-5138
Previously, when DevTools was restarting the application it would
use reflection to run all of the JVM's shutdown hooks. This was done
to close any SpringApplications' application contexts. Unfortunately,
it had the unwanted side-effect of running other shutdown hooks as
well.
The other shutdown hooks were often written with the, entirely
reasonable, expectation that they would only be called when the JVM
was shutting down. Calling them at another time could leave the
hook's library in an unexpected state. One such example is Log4J2
which was worked around in aaae4aa3 (see gh-4279). Another is the
problem with Eureka (see gh-4097). There's no work around for this
problem, even with reflective hackery, hence the change being made
here.
This commit updates the Restarter so that shutdown hooks are no longer
called during a restart. This removes the chance of a restart having
the unwanted side-effect of leaving a third-party library in a broken
state. RestartApplicationListener now prepares the Restarter with the
root application context, and the Restarter then closes it as part of
the restart. The changes have been tested with an application that
uses a single context and an application with a context hierarchy.
Closes gh-4097
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, WebRequestTraceFilter would call request.getParameterMap()
before deciding whether or not the parameters should be included in
the trace. For a POST request, this had the unwanted side-effect
of always reading the request body.
This commit updates WebRequestTraceFilter so that it checks that
parameters are to be included in the trace before calling
request.getParameterMap()
Closes gh-5089
Andy Wilkinson
Stephane Nicoll
Christoph Strobl
Mariusz Kopylec
Brian Clozel
Eddú Meléndez
Oliver Gierke