Update DataSourceAutoConfiguration so that pooled datasource
configurations are only loaded via an @Import. If left as nested
classes, the load order is JVM specific and can result in the wrong
configuration being loaded.
Closes gh-2183
Previously, Spring Boot mapped both `DataSourceProperties` and the actual
`DataSource` implementation to the same prefix. This results in a huge
amount of keys in the `spring.datasource` namespace with no way to
identify those that are valid for the pooled data source in use.
This commit maps the four pooled data sources we support in four isolated
namespace, keeping `spring.datasource` only for the common settings.
These are `spring.datasource.tomcat`, `spring.datasource.hikari`,
`spring.datasource.dbcp` and `spring.datasource.dbcp2` for the Tomcat,
Hikari, Commons DBCP and Commons DBCP2 implementations respectively.
Closes gh-2183
Add SharedMetadataReaderFactoryContextInitializer to ensure that a
shared caching MetadataReaderFactory is used between configuration
classes and auto-configure sorting.
Fixes gh-4993
The `DataSource` auto-configuration in Spring Boot supports two modes:
regular pooled DataSource and embedded database (via the
`EmbeddedDatabase` infrastructure provided by `spring-jdbc`. These were
previously named `NonEmbedded` and `Embedded` respectively.
This commit clarifies those mode and in particular that a pooled
`DataSource` can also handle an embedded database.
Closes gh-4634
Update `ResourceBundleCondition` to only enable the messages source
if `messages.properties` (and not `messages*.properties`) exists. This
operation is much faster that performing a pattern match since a full
jar entry scan is not required.
Since adding `messages.properties` is good practice and this change
allows us to delete the custom `PathMatchingResourcePatternResolver`
it seems like a fine compromise to make.
Fixes gh-4930
See gh-4811
When a Jersey app is deployed to a standalone container, Jersey’s
ServletContainerInitializer will run and register a servlet for a class
annotated with @ApplicationPath. If Jersey’s ServletContainerInitializer
runs before Spring’s, this servlet will take precedence over the
servlet registered by JerseyAutoConfiguration and will therefore not be
configured with any init parameters specified using spring.jersey.init
For the case where Jersey’s SCI runs first, this commit updates
JerseyAutoConfiguration to examine the servlet context for an existing
registration of Jersey’s servlet (Jersey names the registration using
the fully-qualified name of the ResourceConfig subclass). If a
registration is found its init parameters are configured using the
configuration provided by spring.jersey.init.
For the case where Spring’s SCI runs first, this commit updates
JerseyAutoConfiguration so that it names its registration using the
fully-qualified name of the ResourceConfig sub-class. This allows
Jersey’s SCI to find the existing registration rather than attempting
to configure its own.
Closes gh-2471
While Flyway's `MigrationVersion` is a String value, a simple "0" is
also a valid number. When such value is not wrapped in YAML, an integer
is injected rather than a String which leads to a failure as we can't
convert it.
This commit updates the `StringToMigrationVersionConverter` to also
supports conversion from a Number. This is a convenience for users
using YAML for configuration
Closes gh-4981
The same initializer will receive multiple ContextRefreshedEvents
when their is an application context hierarchy. This commit updates
the initializer to correctly handle multiple ContextRefreshedEvents
and only act upon the first that it receives.
See gh-4871
This commit is a continuation of the changes made in b85b608. It
addresses an additional problem when testing applications where two
contexts are refreshed in quick succession. In this scenario, it
was possible, theoretically at least, for the first context’s background preinitialization to still be in progress and creating loggers when the
second is refreshed and resets the logger context.
This commit updates BackgroundPreinitializer so that, upon receipt of
a ContextRefreshedEvent, it waits for preinitialization to have
completed. In the scenario described above, this ensures that
preinitialization has completed before the call to refresh() for the
first context returns, thereby preventing it from running in parallel
with the refresh of the second context.
Closes gh-4871
If Both Hazelcast and Hibernate are available, Spring Boot takes the
opinion that Hazelcast can be used for 2nd level caching and therefore
need to start before Hibernate.
Unfortunately, some users require Hibernate in some of their hazelcast
use case so the link is actually reversed. One way for such user is to
disable the auto-configuration that deals with this link. This class is
now public so that users can locate them and exclude them if necessary.
Closes gh-4960
Previously, BackgroundPreinitializer would kick off preinitialization
on a separate thread in response to an ApplicationStartedEvent. This
work would then race with the logging system being set up in response
to an ApplicationEnvironmentPreparedEvent. When Logback’s being used
this race is problematic. As part of Logback’s setup,
LoggerContext.stop() is called. This calls LoggerContext.reset() which
can fail with a ConcurrentModificationException if another thread tries
to create a Logger at the same time. This is a known bug in Logback [1].
This commit updates BackgroundPreinitializer to respond to
an ApplicationEnvironmentPreparedEvent and to order itself so that it’s
called after LoggingApplicationListener has responded to the same event
by initializing the logging system.
Closes gh-4871
[1] http://jira.qos.ch/browse/LOGBACK-397
Mongo’s 2.x driver allowed the credentials list to be null, however
the 3.x driver requires an empty list instead. The behaviour of the 2.x
driver is the same whether the client is created with a null credential
list or an empty credential list.
This commit aligns with the requirements of the 3.x driver by ensuring
that we never pass in a null credential list when creating the client.
Closes gh-4076
Webjars locator is a good hint that the resource chain should be
enabled. The sole presence of the library now enables the resource chain
unless the configuration states otherwise.
Closes gh-4403
Previously, MustacheViewResolver would create an InputStreamReader
that wraps the template Resource's InputStream but would fail to close
the Reader. When the InputStream was a FileInputStream, this caused
the resolver to leak file handles.
This commit updates the resolver to close the Reader once the Template
has been compiled, thereby allowing any underlying resources to be
cleaned up immediately, rather than having to wait for the JVM to exit.
Closes gh-4921
Phillip Webb
Stephane Nicoll
Eddú Meléndez
Vedran Pavic
Patrick Bray
Huang YunKun
mnhock
Johnny Lim
Spring Buildmaster
Jacques-Etienne Beaudet
Andy Wilkinson