Previously, health contributors in a non-reative app were found by
retrieving them from the application context rather than via
dependency injection. This results in only contributors from the
current context being found, with contributors in ancestor contexts
ignored.
This commit moves to injection of the contributors, aligning the
behaviour with that of a reactive application.
Closes gh-27308
Update `CompositeHandlerExceptionResolver` to search for beans in
all contexts. Note that `BeanFactoryUtils.beansOfTypeIncludingAncestors`
cannot not be used since we need to pick up all beans, even if they
have the same name.
See gh-31495
Update `Log4J2LoggingSystemTests` to exclude Logback and include
'log4j-slf4j-impl'. The `ModifiedClassPathClassLoader` has also been
updated so that it no longer automatically excludes `log4j` artifacts,
instead we now use `@ClassPathExclusions` on the relevant tests.
Fixes gh-19365
- Document that an application key must be set to publish metadata
for the exported metrics.
- Point out that using a non-US Datadog site (e.g., EU) requires
changing the `uri` property.
See gh-30879
In all likelihood there will not be a 2.9 release so this commit
updates the message for deprecations made in 2.7 to indicate that
removal will not occur until 3.0.
See gh-30903
spring.security.saml2.relyingparty.registration.*.asserting-party.* is
now named spring.security.saml2.relyingparty.registration.*.assertingparty.*
Closes gh-30785
Rename spring.security.saml2.relyingparty.registration.*.identity-provider.*
to spring.security.saml2.relyingparty.registration.*.asserting-party.*
The old property names are still supported, but will lead to a warning
in the logs.
Closes gh-30642
Since Micrometer version 1.9.0, the Dynatrace registry uses specialized
instruments by default, which ensures data is exported in an optimal
format. By using this new flag, users can switch back to the previous
behavior, which uses the original instruments from Micrometer.
See gh-30637
Prior to this commit, Spring Boot would only auto-configure the
`RestHighLevelClient` and `RestClientBuilder` if the
`RestHighLevelClient` was present. This was done in 1d73d4ed.
This commit brings back the exposing of the `RestClient` bean in when
exposing the `RestHighLevelClient` or when the `RestHighLevelClient`
is not present. It allows for using the auto-configuration and its
customizers of the `RestClientBuilder` in a similar way as it is done
for the `RestTemplateBuilder` and the `WebClient.Builder`.
The presence of the `elasticsearch-rest-high-level-client` module is
now optional. This opens the door for potentially adding support for
the new Elasticsearch Java Client[1] that is based on the same
`RestClient`.
The health contributor and its configuration has also been updated to
only depend on the low-level RestClient.
See gh-28496
[1] https://github.com/elastic/elasticsearch-java
Madhura Bhave
Adrian Bob
Stephane Nicoll
Phillip Webb
Marc Wrobel
Andy Wilkinson
Johnny Lim
Guirong Hu
Eddú Meléndez
Denis Washington
Moritz Halbritter
Georg Pirklbauer
Filip Hrisafov
luozhenyu
Jonatan Ivanov
Moritz Halbritter