Previously, it was possible for Spring Integration, including its
built-in Micrometer support, to be auto-configured before the
Micrometer auto-configuration had defined the MeterRegistry bean. This
resulted in missing Spring Integration metrics.
Spring Integration is unusual in having its own built-in Micrometer
support that it configures itself. Rather than providing
auto-configuration for Integration's Micrometer support (Which isn't
needed), this commit introduces some auto-configuration that just
affects the ordering of the auto-configuration classes. This ordering
ensures that the MeterRegistry bean has been defined by Spring
Integration is auto-configured. This ensures that the MeterRegistry
bean is known to the BeanFactory when Spring Integration goes looking
for it.
See gh-24095
When running on Java 11 (where `@PostConstruct` is no longer part of
the JRE) and without a dependency on jakarta-annotation-api,
`@PostContruct` annotions are silently dropped. This leads to obscure and
hard-to-track down changes in the behaviour of our auto-configuration
as the `@PostConstruct`-annotated methods are not invoked.
To allow users to run on Java 11 without having jakarta-annotation-api
on the classpath, this commit removes use of `@PostConstruct` from main
code. A Checkstyle rule has also been added to prevent its usage in
main code from being reintroduced.
Closes gh-23723
Previously, the test would make an HTTP request and, as soon as the
response was received, it would check the presence and value of the
http.server.requests meter. This create a race condition between the
meter being registered once the response had been flushed and the
meter's presence being checked. If the check won the race, the test
would fail.
This commit updates the test to wait for up to 5 seconds for the
meter to be present and have a count of 1, matching the single request
that has been made.
Fixes gh-23919
Add a dedicate condition annotation to detect when Spring Security is
available but has not been configured by the user. The new annotation
helps simplify quite a few of our auto-configuration classes.
See gh-23421
Replace `WebSecurityConfigurer` and `WebSecurityConfigurerAdapter`
configurations with `WebSecurityCustomizer` or `SecurityFilterChain`
beans.
Closes gh-23421
Previously, the test would make an HTTP request and, as soon as the
response was received, it would check the presence and value of the
http.server.requests meter. This create a race condition between the
meter being registered once the response had been flushed and the
meter's presence being checked. If the check won the race, the test
would fail.
This commit updates the test to wait for up to 5 seconds for the
meter to be present and have a count of 1, matching the single request
that has been made.
Fixes gh-23863
Previously, the base path of a servlet-based management server could be
configured using management.server.servlet.context-path but there was no
equivalent property for WebFlux.
This commit introduces a new property, management.server.base-path,
that can be used with both servlet and reactive management servers. The
existing servlet-specific property has been deprecated in favour of the
new general property. When using the servlet stack, if both the general
property and the servlet-specific property are set, the new general
property takes precedence. When using the reactive stack, only the new
general property is considered.
Closes gh-22906
This commit makes sure to defer registration of hibernate statistics
outside of the singleton lock as it can lead to deadlocks when the
EntityManagerFactory is initialized in deferred mode.
Closes gh-23740
This commit adds support for Redis cache metrics. Users can opt-in for
statistics using the "spring.cache.redis.enable-statistics" property.
Closes gh-22701
Constructor calls like new AtomicInteger(0) cause a volatile write that
can be saved in cases where the constructor parameter is the default
value.
See gh-23575
Previously, all MeterFilter beans were applied to all MeterRegistry
beans. As a result, when a composite registry was auto-configured, both
the composite and all of its delegates would have the same MeterFilters
applied. This made it impossible for one of the delegate registries to
have a locally-configured filter that would allow a meter that would be
denied by one of the MeterFilter beans applied to the composite.
This commit update MeterRegistryConfigurer to skips the auto-configured
composite meter registry when applying MeterFilter beans to
MeterRegistry beans. As a result, the composite's filters will no
longer deny a meter before it reaches a delegate that would have
accepted it due to one of its locally-configured filters.
Closes gh-23381
With the introduction of health indicators that only require the
CqlSession, this commit deprecates the health indicators that require
Spring Data since the latter build on top of the former.
Closes gh-23226
Prior to this commit, Spring Boot would auto-configure both
Elasticsearch variants: `RestClient` ("Low Level" client) and
`RestHighLevelClient` ("High Level" client).
Since one can be derived from the other, this would create complex and
unclear situations depending on what developers provided with their
configuration.
`RestHighLevelClient` is mostly for actual use of the Elasticsearch API,
with support for specific methods and (de)serialization. On the other
hand, `RestClient` is merely wrapping the Apache HTTP client for
load-balancing support and low level HTTP features.
This commit completely removes the support for `RestClient` in Spring
Boot and now requires the presence of the
`org.elasticsearch.client:elasticsearch-rest-high-level-client`
dependency for REST client support with Elasticsearch.
Closes gh-22358
This commit builds on top of gh-22603 and exposes data collected by the
`BufferingApplicationStartup` on a dedicated `"/startup"` Actuator
endpoint.
Closes gh-23213
Rename `CompositeMeterRegistryAutoConfiguration` to
`MeterRegistryAutoConfiguration` since it can also create non-composite
registries.
Closes gh-22988
