After experimenting with our newly introduced core retry support
(RetryPolicy, RetryTemplate, etc.) and @Retryable support, it
became apparent that there are overlapping concerns between the current
RetryPolicy and BackOff contracts.
- RetryPolicy and BackOff both have stateful executions: RetryExecution
and BackOffExecution. However, only one stateful execution is
necessary.
- FixedBackOff and ExponentialBackOff already incorporate "retry" logic
in terms of max attempts, max elapsed time, etc. Thus, there is no
need to duplicate such behavior in a RetryPolicy and its
RetryExecution.
- RetryTemplate currently accepts both a RetryPolicy and a BackOff in
order to instrument the retry algorithm. However, users would
probably rather focus on configuring all "retry" logic via a single
mechanism.
In light of the above, this commit directly incorporates BackOff
in RetryPolicy as follows.
- Remove the RetryExecution interface and move its shouldRetry() method
to RetryPolicy, replacing the current RetryExecution start() method.
- Introduce a default getBackOff() method in the RetryPolicy interface.
- Introduce RetryPolicy.withDefaults() factory method.
- Completely overhaul the RetryPolicy.Builder to provide support for
configuring a BackOff strategy.
- Remove BackOff configuration from RetryTemplate.
- Revise the method signatures of callbacks in RetryListener.
The collective result of these changes can be witnessed in the
reworked implementation of AbstractRetryInterceptor.
RetryPolicy retryPolicy = RetryPolicy.builder()
.includes(spec.includes())
.excludes(spec.excludes())
.predicate(spec.predicate().forMethod(method))
.maxAttempts(spec.maxAttempts())
.delay(Duration.ofMillis(spec.delay()))
.maxDelay(Duration.ofMillis(spec.maxDelay()))
.jitter(Duration.ofMillis(spec.jitter()))
.multiplier(spec.multiplier())
.build();
RetryTemplate retryTemplate = new RetryTemplate(retryPolicy);
See gh-34716
See gh-34529
See gh-35058
Closes gh-35110
Prior to this commit, `WebMvcConfigurationSupport` would configure file
extensions/media types registrations based on classpath detection.
Since gh-33894, the detection of message converters is located in a
single place, `HttpMessageConverters`.
This commit updates the `WebMvcConfigurationSupport` to use the actual
message converters configured to decide which file extensions should be
set up for content negotiation.
See gh-33894
Prior to this commit, the classpath detection of various
`HttpMessageConverter` types was using an instance `ClassLoader`. The
main goal here was to provide the feature and being able to test it with
filtered classloaders.
It seems this approach fails with GraalVM and we need to ensure that
classpath detection is performed at class loading time for our GraalVM
feature (inlining such static booleans at build time).
As a result, we need to remove the tests for classpath detection.
See gh-33894
This commit uses the new `HttpMessageConverters` class for the HTTP
client (`RestTemplate` and `RestClient`) and HTTP server support.
This effectively removes the duplication of classpath detection for
message converters in multiple places: clients, server and the multipart
converter itself.
Instead of creating multiple instances of the same converters, this
allows applications to share converter instances as much as possible for
better memory efficiency.
As a result, this change also deprecates configuration methods in the
MVC support that are superseded by the new methods introduced for
`HttpMessageConverters` support.
Closes gh-33894
Prior to this commit, Spring Web would configure
`HttpMessageConverter<?>` collections on clients like `RestTemplate` and
on the server infrastructure, in `WebMvcConfigurationSupport`.
This commit introduces a high-level construct for building and
configuring ordered collections of converters.
This includes:
* configuration of well-known converters with classpath detection
* configuration of shared converters, or client/server specific
* configuration of custom converters
See gh-33894
gh-33616 refactored `CachingMetadataReaderFactory` and broke the
behavior as it bypassed the cache for `getMetadataReader(String
className)` operations.
This commit restores the original behavior.
Fixes gh-35112
This commit allows RestClient to handle StreamingHttpOutputMessage
properly by checking the type of the request and invoking setBody()
when appropriate. This improves interoperability with components that
expect streamed output.
A new integration test has been added to verify the functionality.
See gh-35102
Signed-off-by: Daniil Razorenov <daniltmb@gmail.com>
The name is a bit long, but it is necessary to indicate it's a handler
for a deprecation version, and the decision is based on the version,
not an individual endpoint.
See gh-35049
JUnit 5.13 introduced support for Discovery Issues which typically
indicate configuration errors in tests that may result in unexpected
behavior.
Furthermore, discovery issues that are currently reported at INFO level
may later be reported at WARNING or ERROR level -- for example, in
JUnit 6.
In order to ensure that our test suite does not suffer from such
potential errors, this commit sets the
junit.platform.discovery.issue.severity.critical JVM system property to
INFO (instead of leaving it with the default ERROR configuration).
Doing so aligns with our build configuration which fails the build for
selected warnings in Java source code and Javadoc.
If we later determine that INFO causes unnecessary issues for us, we
can switch to WARNING.
This commit also removes two "intentionally invalid" test cases from
AutowiredConfigurationErrorsIntegrationTests, since those test cases
are now reported as invalid as of JUnit 5.13.
Closes gh-35107
Sam Brannen
Juergen Hoeller
rstoyanchev
Brian Clozel
Stefano Cordio
Tran Ngoc Nhan
Daniil Razorenov