As of #33894, `HttpMessageConverters` auto-detects converters and use
custom-provided ones to configure a collection of converters for the
client or the server.
Right now the multipart converter is only configured if core converters
(JSON, XML...) are configured/detected. We do not reuse the base
converters (resource, string, byte array) for the multipart converter
as it applies different encoding defaults (ISO for the main ones, UTF-8
for multipart).
This commit refines the configuration to not only include the multipart
converter when core converters are present, but also if any other
converter was configured.
Closes gh-35203
As of #33894, we introduced a new `HttpMessageConverters` API.
While this achieved our goal of focusing converters classpath detection
in a single place and avoiding waste, a single `HttpMessageConverters`
instance for both client and server added more complexity for developers.
This commit aligns the API here with the WebFlux `CodecsConfigurer` to
opt for a client/server flavor as the first step in the builder.
While this make the sharing of converter instances between server and
client impossible, this allows for a simpler API and separates concerns.
Closes gh-35187
This commit aligns `HttpMessageConverters` with the WebFlux codecs
configuration by adding custom converters first, before the
auto-detected and well-known ones.
This is a general approach in Spring Framework, where custom
implementations are more likely to handle specific uses cases and should
be involved before considering the more general implementations.
Fixes gh-35177
This commit simplifies our dependency management for JUnit artifacts by
making use of the junit-jupiter and junit-platform-suite aggregator
artifacts.
Closes gh-35127
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
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
API version resolution and parsing is already applied as long as
an ApiVersionStrategy is configured and irrespective of whether
a given RequestMapping has a version or not.
RequestMappingHandlerMapping also needs to be aware of the API version
in order to apply deprecated version handling. So it is better to
resolve, parse, and validate the version in the beginning of
handler mapping rather than in the first call to any
VersionRequestCondition.
Closes gh-35049
After further consideration, we have decided to remove the recently
introduced MockSslInfo in favor of introducing the following static
factory methods directly in the SslInfo interface.
- SslInfo.from(String sessionId)
- SslInfo from(String sessionId, X509Certificate... peerCertificates)
See gh-35042
See gh-35078
Prior to this commit, the sslInfo() method in MockServerHttpRequest's
BaseBuilder returned void, which prevented it from being used with the
intended fluent Builder pattern.
This commit changes the return type to the builder (B) for proper method
chaining.
Closes gh-35075
Document that HandlerMethod.toString() is used in log and error messages,
and that the returned description should typically include the method
signature of the underlying handler method for clarity and debugging.
Closes gh-35055
Signed-off-by: WonYong Hwang <111210881+wonyongg@users.noreply.github.com>
Co-authored-by: Sam Brannen <104798+sbrannen@users.noreply.github.com>
This commit fixes a regression introduced in gh-34971 where GET and
DELETE requests would not allow request bodies anymore for
`JdkClientHttpRequest`.
We are now using `builder.GET()` and `builder.DELETE()` methods only if
the provided body is null.
Fixes gh-35068
Prior to this commit, the `DefaultServerWebExchange` would attempt to
decode request bodies as form-data or multipart of the request
content-type was compatible with the expected media types.
If requests are sent with an invalid wildcard content-type such as "*/*"
or "multipart/*", we should not attempt to decode here.
Fixes gh-34660
This commit configures a new CheckStyle rule that fails for empty
"catch" blocks, unless the exception is named "ignored" or "expected".
This also fixes the remaining instances missed by the previous commit.
Closes gh-35047
The Spring codebase sometimes ignores exceptions in catch blocks on
purpose. This is often called out by an inline comment.
We should make this more obvious by renaming the exception argument in
the catch block to declare whether the exception is "ignored" or
"expected".
See gh-35047
Signed-off-by: Vincent Potucek <vpotucek@me.com>
[brian.clozel@broadcom.com: rework commit message]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
Prior to this commit, the WebFlux server support would try reading
form-data from the request by:
* first, checking that request content-type is compatible with a
form-data content-type
* then by selecting a message reader that is compatible with the given
request content-type
This approach is flawed because if the content-type provided by the
request is too broad, another message reader could be selected that's
not meant to be used for reading form-data. Typically, a JSON message
reader could be selected and would fail when reading the request.
This problem was previously hidden because message readers would not
support `MultiValueMap` as a target type. Now that some readers support
this type, this can lead to deserialization errors.
This commit now ensures that in all cases, we attempt to read form-data
with a message reader that supports the
"application/x-www-form-urlencoded" media type.
Fixes gh-34660
Juergen Hoeller