This commit updates the `HttpStatus` enum with the latest changes in
RFC9110:
* deprecate "413 Payload Too Large" in favor of "413 Content Too Large"
* deprecate "418 I'm a teapot" as it was meant as a joke and is now
marked as unused
* Introduce new "421 Misdirected Request"
* deprecate "422 Unprocessable Entity" in favor of
"422 Unprocessable Content"
* deprecate "509 Bandwidth Limit Exceeded" as it's now unassigned
* deprecate "510 Not Extended" as it's now marked as "historic"
The relevant exceptions, test matchers and more have been updated as a
result.
Closes gh-32870
This commit updates Jackson 3 JSON support to use JsonMapper
instead of ObjectMapper in converters, codecs and view constructors.
As a consequence, AbstractJacksonDecoder, AbstractJacksonEncoder,
AbstractJacksonHttpMessageConverter and JacksonCodecSupport are
now parameterized with <T extends ObjectMapper>.
Closes gh-35282
This enhancement enables finer control over interceptor application
based on HTTP methods, aligning with modern Spring 7.x practices.
- Extend MappedInterceptor with include/exclude HTTP methods
- Add constructors for interceptor implementations
- Update InterceptorRegistration with fluent methods
- Keep existing constructors and methods for compatibility
- Update matches() to check HTTP method conditions
See gh-35273
Signed-off-by: SRIRAM9487 <sriram9487tk@gmail.com>
This commit ensures that the original request URI is displayed in
`NoResourceFoundException` error messages when logged. Without this
change, it can be confusing to see only the attempted resource path.
There are cases where the original request was not meant for resource
handling and we want to understand why this wasn't processed by another
handler.
The Problem Detail attribute has not been changed as the "instance"
attribute already displays the request path.
Closes gh-34553
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
Previously, @RequestBody(required = false) annotations declared
on interface methods were ignored when resolving the consumes
condition. This caused mappings to incorrectly require a request
body with a Content-Type such as application/json, even when no
body was provided.
This change uses AnnotatedMethod to retrieve parameter annotations
from both the implementation and its interfaces, ensuring that the
required flag is respected and body presence is evaluated correctly.
Closes gh-35086
Signed-off-by: Renato Mameli <renatomamel410@gmail.com>
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
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
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
Brian Clozel
rstoyanchev
Taeik Lim
Juergen Hoeller
Sam Brannen
Sébastien Deleuze
SRIRAM9487
Renato Mameli
NeatGuyCoding