Prior to this commit (and despite the changes made in commit
4593f877dd), WebSocketHttpHeaders was not compatible with the
HttpHeaders(HttpHeaders) constructor or the copyOf(HttpHeaders) and
readOnlyHttpHeaders(HttpHeaders) factory methods.
To address that, this commit revises the implementation of
WebSocketHttpHeaders so that it only extends HttpHeaders, analogous to
ReadOnlyHttpHeaders. In other words, WebSocketHttpHeaders no longer
stores or delegates to a local HttpHeaders instance.
Closes gh-35792
Since HttpHeaders no longer implements MultiValueMap (see gh-33913),
a few interoperability issues have arisen between HttpHeaders and
WebSocketHttpHeaders.
To address those issues, this commit:
- Revises addAll(HttpHeaders), putAll(HttpHeaders), and putAll(Map) in
HttpHeaders so that they no longer operate on the HttpHeaders.headers
field.
- Overrides addAll(String, List), asSingleValueMap(), and
asMultiValueMap() in WebSocketHttpHeaders.
- Deletes putAll(HttpHeaders), putAll(Map), and forEach(BiConsumer) in
WebSocketHttpHeaders, since they do not need to be overridden.
This commit also removes unnecessarily overridden Javadoc in
WebSocketHttpHeaders and revises the implementation of several methods
in HttpHeaders so that they delegate to key methods such as get()
instead of directly accessing the HttpHeaders.headers field.
See gh-33913
Closes gh-35792
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
Undertow does not support Servlet 6.1, we need to remove compatibility
tests as well as Undertow-specific classes for WebSocket and reactive
support.
Closes gh-35354
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>
- Improve Javadoc.
- Suppress warnings for "removal".
- Update copyright headers.
- Migrate several tests from:
- MappingJackson2MessageConverter to JacksonJsonMessageConverter
- Jackson2JsonEncoder to JacksonJsonEncoder
- Jackson2JsonDecoder to JacksonJsonDecoder
- Jackson2SmileEncoder to JacksonSmileEncoder
- Jackson2ObjectMapperBuilder to JsonMapper and XmlMapper
- MappingJackson2JsonView to JacksonJsonView
- MappingJackson2HttpMessageConverter to JacksonJsonHttpMessageConverter
- MappingJackson2XmlHttpMessageConverter to JacksonXmlHttpMessageConverter
This change removes the `MultiValueMap` nature of `HttpHeaders`, since
it inherits APIs that do not align well with underlying server
implementations. Notably, methods that allows to iterate over the whole
collection of headers are susceptible to artificially introduced
duplicates when multiple casings are used for a given header, depending
on the underlying implementation.
This change includes a dedicated key set implementation to support
iterator-based removal, and either keeps map method implementations that
are relevant or introduces header-focused methods that have a similar
responsibility (like `hasHeaderValues(String, List)` and
`containsHeaderValue(String, String)`).
In order to nudge users away from using an HttpHeaders as a Map, the
`asSingleValueMap` view is deprecated. In order to offer an escape
hatch to users that do make use of the `MultiValueMap` API, a similar
`asMultiValueMap` view is introduced but is immediately marked as
deprecated.
This change also adds map-like but header-focused assertions to
`HttpHeadersAssert`, since it cannot extend `AbstractMapAssert` anymore.
Closes gh-33913
This commit updates the whole Spring Framework codebase to use JSpecify
annotations instead of Spring null-safety annotations with JSR 305
semantics.
JSpecify provides signficant enhancements such as properly defined
specifications, a canonical dependency with no split-package issue,
better tooling, better Kotlin integration and the capability to specify
generic type, array and varargs element null-safety. Generic type
null-safety is not defined by this commit yet and will be specified
later.
A key difference is that Spring null-safety annotations, following
JSR 305 semantics, apply to fields, parameters and return values,
while JSpecify annotations apply to type usages. That's why this
commit moves nullability annotations closer to the type for fields
and return values.
See gh-28797
rstoyanchev
Juergen Hoeller
Sam Brannen
Sébastien Deleuze
KNU-K
Brian Clozel
Jeroen Meijer
Spring Builds
Vincent Potucek
Taeik Lim
Jared Wiltshire
Daeho Kwon
Mengqi Xu
Sébastien Deleuze
Simon Baslé