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
rstoyanchev