This commit makes sure that properties-based resource bundle location
with a dot is detected. It also harmonizes the description of the
configuration key as our support is not stricly matching the convention.
Closes gh-10092
jOOQ auto-configuration will make use of a PlatformTransactionManager
bean if available. This commit ensures that jOOQ is auto-configured
after transaction auto-configuration, thereby ensuring that any
auto-configuration PlatformTransactionManager bean can be consumed.
Closes gh-11052
The JobLauncherCommandLineRunner reassigned method arguments inside the
merge method. Instead of reassigning the method argument just return
the new instance directly.
Also some minor cleanup (unnesseccary null check and continue keyword).
Closes gh-10612
Previously, if a user's configuration class provided a custom
Validator bean, that configuration class would be initialized very
early so that the Validator could be used to create the
auto-configured MethodValidationPostProcessor. This early
initialization could problems as it may prevent any of the
configuration class's dependencies from being post-processed.
This commit updates the injection of the Validator bean to be lazy,
thereby preventing the creation of the auto-configured
MethodValidationPostProcessor from triggering early initialization.
Closes gh-9416
Neo4jDataAutoConfiguration is meant to kick in when Spring Data Neo4J is
on the classpath. Yet, we were only checking for the presence of neo4j
itself and the transaction manager provided by spring-tx.
This commit makes sure to back off if Spring Data Neo4J is not present.
Closes gh-10038
Previously, background preinitialization was started in response to
an ApplicationEnvironmentPreparedEvent and would complete at an
undetermined time later. This opened a window where SpringApplication
run could return and background preinitialization could still be
in progress. If, within this window, something attempted to configure
the logging system, an IO failure could occur as logging on the
background preinitialization thread would attempt to use resources
that had been closed.
This commit updates BackgroundPreinitializer so that it waits for
preinitialization to have completed when it receives an application
ready or application failed event. This prevents SpringApplication
run from returning while preinitialization is still in progress,
closing the window described above.
With info level logging enabled it appears that background
preinitialization consistently completes before the application ready
event is published. As a result, waiting should have no adverse effect
on performance in normal circumstances. With logging configured such
that background preinitialization outputs a large volume of log
messages (enabling trace logging for the root logger, for example), it
will be slowed down sufficiently for waiting to be necessary.
Closes gh-5669
Background preinitialization triggers static initialization of a
number of components that are slow to initialize. As the
initialization is static, it's only necessary once per class loader.
Previously, a new background preinitialization thread would be
created and started for each ApplicationEnvironmentPreparedEvent.
This commit updates the preinitializer to only create and start the
thread if preinitialization has not already been started for the
current class loader.
Closes gh-9869
Update `@ImportAutoConfiguration` so that it is no longer annotated with
`@AutoConfigurationPackage` and as such isn't a marker for
`AutoConfigurationPackages`.
Having `@ImportAutoConfiguration` marked as an auto-configuration
package is particularly problematic in tests since it frequently breaks
context caching.
Fixes gh-9282
This commit expands the support of PooledConnectionFactory so that
binding the third party object is no longer necessary. All 3rd party
properties are now deprecated in favour of our explicit support.
The main reason behind this change is that a `connection-factory` and
`properties` property were exposed. The former is used to set the
`ConnectionFactory` and makes no sense as a key. The latter is
rebuilding the underlying `ActiveMQConnectionFactory` at each call
without reusing any existing settings.
Closes gh-9837
Previously, if a user's configuration class provided a custom
Validator bean, that configuration class would be initialized very
early so that the Validator could be used to create the
auto-configured MethodValidationPostProcessor. This early
initialization could problems as it may prevent any of the
configuration class's dependencies from being post-processed.
This commit updates the injection of the Validator bean to be lazy,
thereby preventing the creation of the auto-configured
MethodValidationPostProcessor from triggering early initialization.
Closes gh-9416
This commit removes the only use of the `javax.annotation.Resource`
annotation from the codebase. This ensures that injection point are
only defined with Spring's annotation model.
Closes gh-9441
In an MVC web application, DelegatingWebMvcConfiguration provides the
ConversionService while also consuming WebMvcConfigurerAdapters that,
among other things, can configure HTTP message converters. Boot's
WebMvcConfigurerAdapter, WebMvcAutoConfigurationAdapter, consumes
the HttpMessageConverters bean and uses it to configure Spring MVC's
HTTP message converters. This can create a bean dependency cycle if
an HTTP message converter bean depends, directly or indirectly on
the ConversionService. An example of the cycle is:
┌─────┐
| jsonComponentConversionServiceCycle.ThingDeserializer defined in …
↑ ↓
| org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$EnableWebMvcConfiguration
↑ ↓
| org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter
↑ ↓
| org.springframework.boot.autoconfigure.web.HttpMessageConvertersAutoConfiguration
↑ ↓
| mappingJackson2HttpMessageConverter defined in class path resource [org/springframework/boot/autoconfigure/web/JacksonHttpMessageConvertersConfiguration$MappingJackson2HttpMessageConverterConfiguration.class]
↑ ↓
| jacksonObjectMapper defined in class path resource [org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration$JacksonObjectMapperConfiguration.class]
└─────┘
This commit breaks the cycle by making WebMvcAutoConfigurationAdapter
consume HttpMessageConverters lazily. This allows the adapter to be
created without triggered instantiation of every HTTP message
converter bean and all their dependencies. This allows it to be
injected into DelegatingWebMvcConfiguration without triggering an
attempt to retrieve the ConversionService.
Closes gh-9409
Previously, when the liquibase.url, .username, and .password
properties were used to configure a DataSource specifically for
Liquibase that DataSource would never be explicitly closed. As it is
created by DataSourceBuilder with no explicitly configured type it
will use whichever connection pool is available and, therefore, will
create and keep open the pool's minimum number of connections. This
is an unnecessary use of resources both in the application and in the
database.
This commit updates LiquibaseAutoConfiguration so that if it uses
DataSourceBuilder to create a DataSource then it will also close that
DataSource once the database has been migrated.
Closes gh-9218
Move `spring.rabbitmq.listener.*` to `spring.rabbitmq.listener.simple.*`
in preparation for Spring AMQP 2.0 that supports different container
types.
Closes gh-9108
See gh-9055
This commit ensures that a primary JSR 303 and Spring Validator will be
exposed if the auto-configuration kicks in. As `LocalValidatorFactoryBean`
exposes 3 contracts (JSR-303 `Validator` and `ValidatorFactory` as well as
the `Spring` validator one), this makes sure that those types can be
injected by type.
`LocalValidatorFactoryBean` exposes 3 contracts and we're only checking
for the absence of a `javax.validation.Validator` to auto-configure a
`LocalValidatorFactoryBean`. If no standard JSR validator exists but a
Spring's `Validator` exists and is primary, we shouldn't flag the
auto-configured one as `@Primary`. Previous iterations on this feature
have made sure that we'll auto-configure at most one
`javax.validation.Validator` so not flagging it `@Primary` is no problem.
This commit also restores and adds tests that validates
`ValidationAutoConfiguration` will configure a JSR validator even if a
Spring Validator is present.
This effectively fixes gh-8495 in a different way.
Closes gh-8979
Closes gh-8976
`BasicErrorControllerIntegrationTest` is handling the context in each test
and yet it starts a useless test via `@SpringBootTest`. This commit
removes the useless runner and associated annotations.
Replace the MVC validator post processor with an `@Import` so
that a "cannot enhance @Configuration bean definition"
warning does not occur.
Fixes gh-8951
See gh-8495
Update `PropertiesLauncher` so that classes can be loaded outside of
`BOOT-INF/classes`. You can use a subdirectory, or the root directory
of an external jar (but not the parent archive to avoid issues
with agents and awkward delegation models).
Fixes gh-8480
Closes gh-8486
Relax `SpringBootTestContextBootstrapper` rules so that a test can
specify an `ApplicationContextInitializer` and still have
`@SpringBootConfiguration` detected.
Prior to this commit detection would not occur because it's possible
that an initializer _could_ register configuration. This scenario is
actually quite unlikely to occur, certainly less likely than wanting to
use an initializer in combination with auto-detection.
Fixes gh-8483
Update `ValidationAutoConfiguration` and `WebMvcAutoConfiguration` to
ensure as much as possible that only a single Validator bean of each
type is registered.
Validation auto-configuration now does the following:
- If no validator is found: Registers a `LocalValidatorFactoryBean`
(providing both Spring and JSR validation)
- If the user defines a Spring & JSR validator: Backs off
- If the user defines only a JSR validator: Adapts it to a Spring
validator (without exposing another JSR implementation)
WebMvcAutoConfiguration auto-configuration has been updated to make
MVC validation follow common Spring Boot patterns:
- If not validator beans are found (due to the user excluding
ValidationAutoConfiguration) a new `mvcValidator` bean will be
registered.
- If a single validator bean is found it will be used for MVC
validation.
- If multiple validator beans are defined it will either use the one
named `mvcValidator` or it will register a new `mvcValidator` bean
Any automatically registered `mvcValidator` bean will not implement
the JSR validator interface.
Finally, it is no longer possible to provide an MVC validator via a
`WebMvcConfigurer`.
Fixes gh-8495
Allow `PathExtensionContentNegotiationStrategy` to be bypassed by
actuator endpoints. Prior to this commit calling `/loggers/com.aaa.cab`
would return a HTTP 406 response due to `.cab` being a known extension.
Fixes gh-8765
Update `ResourceServerTokenServicesConfiguration` to fail fast if the
`getKeyFromServer()` call fails. Since the key is part of the singleton
`JwtAccessTokenConverter` bean there is not real way to refresh without
restarting the application.
A hard failure seems preferable to an inconsistent state.
Closes gh-8924
This commit makes sure to honour the `spring.aop.proxy-target-class`
property if set by the user. Previously, the
`PersistenceExceptionTranslationPostProcessor` was always configured to
use cglib, regardless of the value of that property.
Closes gh-8887
This commit makes sure to honour the `spring.aop.proxy-target-class`
property if set by the user. Previously, the
`MethodValidationPostProcessor` was always configured to use cglib,
regardless of the value of that property.
Closes gh-8869
Previously, as a result of the changes made in de50cfa21e, an
application would fail to start on Google AppEngine as it prevents
the creation of new threads.
This commit updates OnClassCondition so that it falls back to
performing the work on the main thread when its unable to shift it
to a separate thread.
Closes gh-8584
When used as a meta-annotation the value() attribute of
@ConditionalOnClass will fail silently resulting in the @Conditional
nature of the annotation being ignored.
See gh-8185
Previously, WelcomePageHandlerMapping would forward to index.html.
This assumed that the static path pattern was always /**. If it had
been customised to, for example, /foo/**, then the forward would still
be to index.html and a 404 would result as the page is actually
available at /foo/index.html.
At first glance, it would appear that the forward should be made to
foo/index.html. However, as it's a forward rather than a redirect,
any relative URLs in the index.html page would then be resolved using
/ whereas they should be resolved using /foo/. This could be addressed
by using a redirect rather than a forward, but we don't want to do
that as it's more invasive and would require a roundtrip back to the
client. Instead, this commit simply stops performing the forward when
the static path pattern is not /**.
Closes gh-8788
This commit makes sure that `@EnableTransactionManagement` is
auto-configured with Neo4j. It actually reuses what was done in #8434,
making sure that the `Neo4jDataAutoConfiguration` is ordered properly.
Closes gh-8587
Previously to this commit, transaction management was only enabled when
a `DataSource` is configured. The processing of `@Transactional`
annotations are now enabled as long as a `PlatformTransactionManager` is
present.
Also, the `spring.aop.proxy-target-class` is now honoured if set, still
defaulting to CGLIB mode.
Closes gh-8434
This commit makes sure that if a `javax.cache.CacheManager` is required,
an auto-configured `HazelcastInstance` is fully resolved first. This
prevents the case where the JCache bootstrap actually starts an instance
early, followed by a second (potentially unwanted) instance created by the
regular auto-configuration.
Since the JCache implementation works with an `HazelcastInstance` behind
the scenes, if there is one `HazelcastInstance` configured and it has a
name, then we configure the `CacheProvider` to use that. Future Hazelcast
version will allow to pass the instance directly (i.e. not requiring an
actual name).
Closes gh-8484
This commit flags the two `BeanPostProcessors` registered by the
embedded support as `synthetic` so that they don't trigger an early
initialization of other components.
Closes gh-8467
