ServerWebExchange.Builder has an additional Consumer-style shortcut
method that accepts a builder for modifying the request.
ServerWebExchange and ServerHttpRequest builders have fewer methods,
more use-case focused vs matching directly to properties.
ServerWebExchange now provides access to "requestParams" as a
MulitValueMap with query parameters and form data combined.
The combined map is then used for the params condition of
@RequestMapping purposes () and also for @RequestParam arguments.
Issue: SPR-15000
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
Remove duplicated ServerHttpResponse#setComplete also declard in the
parent ReactiveHttpOutputMessage interface.
Also rename:
ServerWebExchange.MutativeBuilder --> ServerWebExchange.Builder
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
- 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
When getting the lookup path of a resource, both query params and hashes
should be removed from the request path.
This commit fixes the public path resolution for paths like
`/resources/main.svg#icon-hamburgermenu`.
Issue: SPR-14928
This commit adds the ability to serve Resources (static files) through a
RouterFunction. Two methods have been added to RouterFunctions: one that
exposes a given directory given a path pattern, and a generic method
that requires a lookup function.
Issue: SPR-14913
In general, web.util is supposed to remain lowest-level, not depending on any other web.* package. Since web.client also has a support package, a corresponding web.server.support package seemed appropriate for a helper class depending on ServerWebExchange in web.server itself.
Main differences with the Spring MVC original implementation:
- Default redirect HTTP code is 303 See Other since we can assume
all HTTP clients support HTTP 1.1 in 2016
- No more http10Compatible property, use statusCode instead
- By default the redirect is relative to the context path
- A builder allow to set various properties if needed
- In UrlBasedViewResolver, a Function<String, RedirectView>
redirectViewProvider property allows to customize RedirectView
instances in a flexible way
Issue: SPR-14534
This commit polishes Kotlin nullable support by reusing
MethodParameter#isOptional() instead of adding a new
MethodParameter#isNullable() method, adds
Kotlin tests and introduces Spring Web Reactive
support.
Issue: SPR-14165
Multi-value async attributes like Flux and Observable in the model
are treated with Collection semantics and resolved to Mono<List<?>>
prior to rendering.
When resolved through the `GzipResourceResolver`, CSS files can be
resolved as their pre-gzipped variant, if a ".gz" file is present in the
configured resource locations.
Such resources are gzipped and thus should not be transformed by
`CssLinkResourceTransformer`s, since rewriting those would need to
uncompress/transform/recompress. This would lead to poorer performances
than resolving plain resources and delegating compression to the
container.
This commit checks for `GzippedResource` instances in
`CssLinkResourceTransformer` and avoids processing them.
Issue: SPR-14773
If the body class is not resolvable from the return type and there is
a body instance we now fall back on the class of the body instance.
Issue: SPR-14877
Prior to this commit, the wrong `HandlerResultHandler` could be
resolved when handling exceptions; this could happen only if the
original handler and exception handler had different signatures:
```
Publisher<String> originalHandler() { ... }
@ExceptionHandler(MyCustomException.class)
ResponseEntity<Mono<String>> handleException() { ... }
```
In that case, the `ResponseBodyResultHandler` would be used when
handling exceptions instead of the `ResponseEntityResultHandler`.
This commit ensures that the `HandlerResult` returned by the exception
handler is used to resolve the `HandlerResultHandler`. The latter will
process the result and use it to write to the HTTP response.
Issue: SPR-14876
This commit adds support for `@ResponseStatus` annotations on reactive
controller methods. `HandlerResultHandler`s implementations now
set the status on the `ServerWebExchange`, if and only if the
invocation of the controller method succeeded.
Issue: SPR-14830
