This is similar to the WriteListener changes on the ServerHttpResponse
where we are more naturally exposed to a delayed write. Nevertheless
we could also have a delayed read and should be consistent. The early
initialization of the RequestBodyPublisher also simplifies the
internal implementation a bit.
Instead of registering an AsyncListener in ServletHttpHandlerAdapter
we now register an AsyncListener in each of the request and response
where the events need to be handled anyway. This allows removing the
package private delegation methods in the request and response.
This commit makes it possible for handler functions to return
asynchronous status codes and headers, by making HandlerFunction.handle
return a Mono<ServerResponse> instead of a ServerResponse. As a
consequence, all other types that deal with HandlerFunctions
(RouterFunction, HandlerFilterFunction, etc.) had to change as well.
However, when combining the above change with method references (a very
typical use case), resulting signatures would have been something like:
```
public Mono<ServerResponse<Mono<Person>>> getPerson(ServerRequest request)
```
which was too ugly to consider, especially the two uses of Mono. It was
considered to merge ServerResponse with the last Mono, essentialy making
ServerResponse always contain a Publisher, but this had unfortunate
consequences in view rendering.
It was therefore decided to drop the parameterization of ServerResponse,
as the only usage of the extra type information was to manipulate the
response objects in a filter. Even before the above change this was
suggested; it just made the change even more necessary.
As a consequence, `BodyInserter` could be turned into a real
`FunctionalInterface`, which resulted in changes in ClientRequest.
We did, however, make HandlerFunction.handle return a `Mono<? extends
ServerResponse>`, adding little complexity, but allowing for
future `ServerResponse` subtypes that do expose type information, if
it's needed. For instance, a RenderingResponse could expose the view
name and model.
Issue: SPR-14870
Similar pattern as for ServerWebExchange with a default mutate method
on ServerHttpRequest returning a Builder and eventually creating an
immutable wrapper.
HttpHandlerAdapterSupport uses the builder to set the contextPath.
Remove duplicated ServerHttpResponse#setComplete also declard in the
parent ReactiveHttpOutputMessage interface.
Also rename:
ServerWebExchange.MutativeBuilder --> ServerWebExchange.Builder
This commit makes it possible for a ChannelInterceptor to override the
user header in a Spring Message that contains a STOMP CONNECT frame.
After the message is sent, the updated user header is observed and
saved to be associated with session thereafter.
Issue: SPR-14690
Now that reactor/reactor-netty#12 is fixed, we can restore the
previously ignored integration tests.
New tests are hanging, so this commit is converting the `StepVerifier`
`verify()` calls to using actual timeouts.
Issue: SPR-14975
The WebSocketHandler adapters for all runtimes now extend
WebSocketHandlerAdapterSupport, which now also exposes
a shared DataBufferFactory property initialized from the response.
Issue: SPR-14527
suspend/resumeReceiving in the AbstractListenerWebSocketSession are
now abstract methods. In Tomcat/Jetty these methods are no-op
implementations that are then coupled with a buffering strategy via
Flux#onBackpressureBuffer. In Undertow they rely on flow control for
receiving WebSocket messages.
Issue: SPR-14527
- Added suspended flag to indicate whether the ReceivePublisher
is able to process the incoming messages.
- Use buffer strategy for the incoming messages.
Issue: SPR-14527
Dropped "Support" from the name since it not only provides support
methods but actually implements WebSocketSession.
Renamed inner classes:
WebSocketMessagePublisher -> WebSocketReceivePublisher
WebSocketMessageProcessor -> WebSocketSendProcessor
Add protected getter for sendProcessor.
Reduce scoping:
WebSocketReceivePublisher -> private
WebSocketSendProcessor -> protected
WebSocketSendProcessor#setReady -> public (class is still protected)
A few more method name alignments and Javadoc updates.
Issue: SPR-14527