Prior to this commit, the reference manual mentioned that the JSP
<form:input> tag supports HTML5-specific types, but the Javadoc and
spring-form.tld did not document the `type` attribute at all, and none
of the documentation explained which types are supported or that
<form:password> must be used for password fields.
This commit updates the documentation as follows.
- Document in InputTag, spring-form.tld, and the reference manual that
a `type` can be supplied as a dynamic attribute, that `checkbox` and
`radio` are not supported, and that the bound value is rendered as-is.
- Add notes to InputTag, the reference manual, and spring-form.tld
stating that <form:input type="password"> must not be used and that
<form:password> should be used instead.
- Document in PasswordInputTag, spring-form.tld, and the reference
manual that <form:password> does not render the bound value by default.
Closes gh-37376
Prior to this commit, some same-page links in our Antora-based docs
were written using the `xref:` macro, which Antora resolves as a
cross-page reference. However, a same-page target can be misread as a
page reference and break the site build (as nearly happened in
gh-37152), whereas `<<id,text>>` only ever resolves against the current
page's own anchors.
To address that inconsistency and avoid potential future bugs (broken
links), this commit converts all such same-page `xref:` links to
`<<id,text>>`, leaving genuine cross-page `xref:` links are unaffected.
Closes gh-37161
Prior to this commit, the `SockJsClient` would use the
`RestTemplateXhrTransport`. `RestClient` is a modern replacement for
RestTemplate and should be used instead.
This commit introduces the `RestClientXhrTransport` variant as an
immediate replacement.
Closes gh-36566
Prior to this commit, the `FormHttpMessageConverter` would only support
`MultiValueMap` payloads for reading and writing. While this can be
useful when web forms contain multiple values under the same key, this
prevent developers from using a common `Map` type and factory methods
like `Map.of(...)`.
This commit relaxes constraints in `FormHttpMessageConverter` and
ensures that `Map` types are supported for reading and writing URL
encoded forms.
Note that when reading forms to a `Map`, only the first value for each
key will be considered and other values will be dropped if they exist.
Closes gh-36408
Prior to this commit, gh-36255 introduced the new
`MultipartHttpMessageConverter`, focusing on multipart message
conversion in a separate converter. The `FormHttpMessageConverter` did
conflate URL encoded forms and multipart messages in the same converter.
With the introduction of the new converter and related types in the same
package (with `Part`, `FormFieldPart` and `FilePart`), we can now
revisit this arrangement.
This commit restricts the `FormHttpMessageConverter` to URL encoded
forms only and as a result, changes its implementation to only consider
`MultiValueMap<String, String>` types for reading and writing HTTP
messages. Because type erasure, this converter is now a
`SmartHttpMessageConverter` to get better type information with
`ResolvableType`.
As a result, the `AllEncompassingFormHttpMessageConverter` is formally
deprecated and replaced by the `MultipartHttpMessageConverter`, by
setting part converters explicitly in its constructor.
Closes gh-36256
Prior to this commit, Spring web frameworks were using the
"application/x-ndjson" media type for streaming JSON payloads delimited
with newlines.
The "application/jsonl" media type seems to gain popularity in the
broader ecosystem and could supersede NDJSON in the future. This commit
adds support for JSON Lines as an alternative.
Closes gh-36485
Sam Brannen
Tran Ngoc Nhan
rstoyanchev
Gabriel Gerhardt
Brian Clozel
Yurii Platunov
Ivars Silamiķelis
Sébastien Deleuze
hojeong
Philip Bolting