Rework a few parts of the diagnostics support:
- Move code from SpringApplication to FailureAnalyzers
- Allow AbstractFailureAnalyzer to take generic cause type
- Move own analyzers into a new package and make package private
See gh-4907
This commit introduces a new failure analysis mechanism that can be
used to provide diagnostics to a user when their application fails
to start.
When application context refresh fails. FailureAnalyzer
implementations are loaded via spring.factories. The analyzers are
called in order, with the first non-null analysis of the failure
being used. The analysis is reported to the use by
FailureAnalysisReporters which are also loaded via spring.factories.
A single FailureAnalysisReporter is provided out of the box. It logs
an error message with details of the analysis, providing the user
with a description of the failure and, if available, some actions
that they may be able to take to resolve the problem without also
displaying a stack trace that is of little value.
Two analysers are provided initially. One for an embedded servlet
container port clash and another for BeanCurrentlyInCreationExceptions.
More analysers are planned (for UnsatisfiedDependencyException and for
NoUniqueBeanDefinitionException) once some updates have been made
to Spring Framework to make those failures more amenable to analysis.
Closes gh-4907
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
Phillip Webb
Andy Wilkinson
Pedro Costa
Stephane Nicoll
Christoph Strobl
Mariusz Kopylec
Brian Clozel
Eddú Meléndez
Oliver Gierke