@@ -673,48 +673,45 @@ readers and writers for form data, multipart requests, and server-sent events.
673
673
[[webflux-codecs-jackson]]
674
674
==== Jackson JSON
675
675
676
- The decoder relies on Jackson's non-blocking, byte-array parser to parse a stream of byte
677
- chunks into a `TokenBuffer` stream, which can then be turned into objects with Jackson's
678
- `ObjectMapper`. The JSON and https://github.com/FasterXML/smile-format-specification[Smile]
679
- (binary JSON) data formats are currently supported.
676
+ JSON and binary JSON (https://github.com/FasterXML/smile-format-specification[Smile]) data
677
+ formats are both supported.
680
678
681
- The encoder processes a `Publisher<?>`, as follows:
679
+ The `Jackson2Decoder` uses Jackson's asynchronous, non-blocking parser to create a stream
680
+ of ``TokenBuffer``'s and then each `TokenBuffer` is passed to Jackson's `ObjectMapper` to
681
+ create a higher level object. When decoding to a multi-value publisher (e.g. `Flux`), the
682
+ input stream can be a JSON array, or
683
+ https://en.wikipedia.org/wiki/JSON_streaming[line-delimited JSON] if the content-type is
684
+ "application/stream+json".
682
685
683
- * If the `Publisher` is a `Mono` (that is, a single value), the value is encoded when available.
684
- * If media type is `application/stream+json` for JSON or `application/stream+x-jackson-smile`
685
- for Smile, each value produced by the `Publisher` is encoded individually (and followed
686
- by a new line in JSON).
687
- * Otherwise, all items from the `Publisher` are gathered in with `Flux#collectToList()`,
688
- and the resulting collection is encoded as an array.
686
+ The `Jackson2Encoder` works as follows:
689
687
690
- As a special case to the preceding rules, the `ServerSentEventHttpMessageWriter` feeds items
691
- emitted from its input `Publisher` individually into the `Jackson2JsonEncoder` as a
692
- `Mono<?>`.
688
+ * For a single value publisher (e.g. `Mono`), simply serialize it.
689
+ * For a multi-value publisher with "application/json", collect the values with
690
+ `Flux#collectToList()` and then serialize the resulting collection.
691
+ * For a multi-value publisher with a streaming media type such as
692
+ `application/stream+json` or `application/stream+x-jackson-smile`, encode, write, and
693
+ flush each value individually using a
694
+ https://en.wikipedia.org/wiki/JSON_streaming[line-delimited JSON] format.
695
+ * For Server Sent Events, the `Jackson2Encoder` is invoked individually for each event
696
+ by the `ServerSentEventHttpMessageWriter` the resulting output flushed.
693
697
694
- Note that both the Jackson JSON encoder and decoder explicitly back out of rendering
695
- elements of type `String`. Instead `String` instances are treated as low level content ( that is,
696
- serialized JSON) and are rendered as-is by the `CharSequenceEncoder`. If you want a
697
- `Flux<String>` rendered as a JSON array, you have to use `Flux#collectToList()` and
698
- provide a `Mono<List<String>>` instead .
698
+ By default `Jackson2Encoder` and `Jackson2Decoder` do not support serialization for
699
+ elements of type `java.util. String`. Instead the default assumption is that a string
700
+ or a sequence of strings represent serialized JSON content, to be rendered by the
701
+ `CharSequenceEncoder`. If what you want is to render a JSON array from `Flux<String>`,
702
+ use `Flux#collectToList()` and provide a `Mono<List<String>>` to be serialized .
699
703
700
704
701
705
702
706
[[webflux-codecs-streaming]]
703
- ==== HTTP Streaming
707
+ ==== Streaming
704
708
[.small]#<<web.adoc#mvc-ann-async-http-streaming,Same as in Spring MVC>>#
705
709
706
- When a multi-value reactive type such as a `Flux` is used for response rendering, it may
707
- be collected to a `List` and rendered as a whole (for example, a JSON array), or it may be treated
708
- as an infinite stream with each item flushed immediately. The determination for which is
709
- which is made based on content negotiation and the selected media type, which may imply a
710
- streaming format (for example, `text/event-stream`, `application/stream+json`) or not
711
- (for example, `application/json`).
712
-
713
- When streaming to the HTTP response, regardless of the media type (for example, `text/event-stream` and
714
- `application/stream+json`), it is important to send data periodically, since the write would
715
- fail if the client has disconnected. The send could take the form of an empty
716
- (comment-only) SSE event or any other data that the other side would have to interpret as
717
- a heartbeat and ignore.
710
+ When streaming to the HTTP response (for example, `text/event-stream`,
711
+ `application/stream+json`), it is important to send data periodically, in order to
712
+ reliably detect a disconnected client sooner rather than later. Such a send could be an
713
+ comment-only, empty SSE event or any other "no-op" data that would effectively serve as
714
+ a heartbeat.
718
715
719
716
720
717
0 commit comments