Previously, environment binding always happened in a post processor once
the bean has been created. Constructor binding requires to perform the
binding at creating time so this commit performs binding at creation
time if possible.
When this happens, a special `ConfigurationPropertiesBeanDefinition` is
created with a supplier that invokes the binder. To avoid a case where
a bean is processed twice, the post-processor now ignores any bean that
has already been bound to the environment.
Closes gh-8762
Co-authored-by: Madhura Bhave <mbhave@pivotal.io>
AssertJ includes a change in 3.12 that means that, by default, it now incorrectly
identifies some of the builder methods on CacheControl as accessor methods for its fields.
This commit restores the behaviour of 3.11 so that a method is only considered to be a
property accessor if a matches the Java bean naming conventions.
Closes gh-16145
This commit switches the default value for the `spring.jmx.enabled`
configuration property.
JMX is now disabled by default and can be enabled with
`spring.jmx.enabled=true`.
Closes gh-16090
This includes tests for the autoconfiguration using that new property.
The test require the native types for Bolt and embedded in the test
scope, so the Neo4j-OGM native types have been added to managed
dependencies.
The enhanced autoconfiguration throws an
InvalidConfigurationPropertyValueException when native types cannot be
used due to missing dependencies or wrong transport mode.
See gh-15637
Previously, the auto-configuration for both Jersey and WebMvc would auto-configure
a RequestContextFilter bean. In 2.1.0, this led to a startup failure due to the latter
attempting to override the bean defined by the former. In addition to the override there
were also problems with the order of the filter as Jersey uses -1 and MVC uses -105.
To avoid the above-described problems, the auto-configuration of the RequestContextFilter
was removed from JerseyAutoConfiguration in 2.1.1. Unfortunately, the broke
request-scoped beans for those using only Jersey.
This commit attempts to strike a better balance by reintroducing the auto-configuration
of RequestContextFilter in JerseyAutoConfiguration. It will back off if the user defines
their own filter or filter registration. WebMvcAutoConfiguration has been updated to
back off in the same manner. This leaves the potential for ordering problems, but they
are no worse than they were before. Furthermore, the user has the means to correct any
problems by using the various filter ordering properties that are provided for Jersey,
Spring Session, Spring Security, etc.
Closes gh-15376
This commit also ensures that Jersey-based actuator endpoints are
available before the user has configured a `ResourceConfig` bean
Fixes gh-15625
Fixes gh-15877
Prior to this commit, errors unhandled by custom `WebExceptionHandler`
and resulting in an HTTP 500 status would not be logged at ERROR level,
giving no information to developers about the actual exception.
This commit ensures that such exceptions are logged at the ERROR level
with their exception. By the time the exception hits the
`DefaultErrorWebExceptionHandler`, if the response is already committed
or if the exception is due to a client disconnecting, the error is
delegated to Framework support as Spring Boot won't be able to render an
error page as expected.
Fixes gh-15769
Spring Boot provides two separate auto-configurations that can
potentially expose an `AsyncTaskExecutor` implementation so relying on
the presence of a single instance is too weak.
This commit fixes the detection of the AsyncTaskExecutor that can be
used to bootstrap JPA so that a single instance is used and, in the case
more than one exists, the one named `applicationTaskExecutor`.
Closes gh-15447