This commit introduces a new AbstractReactiveWebInitializer in
spring-web that relies on WebHttpHandlerBuilder to detect request
processing infrastructure beans from an ApplicationContext.
This eliminates the need to create a DispatcherHandler, since it is
expected to be a Spring bean, and as a result the initializers in
spring-webflux have been deprecated.
Issue: SPR-16144
FromHttpMessageWriter and MultipartHttpMessageWriter both support
MultiValueMap except the former supports String values only. This
presents an issue since either full generic type information must be
provided, which is cumbersome on the client side, or if left out there
is no good way to order the writers to make a proper decision.
This commit:
- refines the canWrite behavior of to not a
accept MultiValueMap without proper generic information unless the
MediaType is explicitly set providing a strong hint.
- modifies MultipartHttpMessageWriter to be configured with a
FormHttpMessageWriter so it can write both plan and multipart data with
the ability to properly differentiate based on actual map values.
Issue: SPR-16131
This commit exposes the ClientRequest's URL and HttpMethod fields via a
setter, so that they can be changed more easily in a request that was
created via ClientRequest.from(ClientRequest).
Issue: SPR-16093
Before this commit, when adding filters to a builder obtained via
`WebClient.mutate()`, the filters were added both to the original client
as well as the mutated builder. This commit fixes that.
Issue: SPR-16059
Prior to this commit, the `ResourceWebHandler` would itself handle the
response with an HTTP 404 in many cases, including a missing static
resource.
This does not give a chance to `WebExceptionHandler` instances to handle
that error and, for example, display an error page.
See spring-projects/spring-boot#8625
Issue: SPR-16023
Concrete server and client, reactive request and response
implementations should not have to be accessed outside their package.
They could be seen as private to their HttpHandler adapters and
ClientHttpConnector's respectively.
The one exception, WebSocket upgrades in spring-webflux, is an internal
framework use case, accommodated via downcast + accessors in the
abstract base classes.
Prior to this commit, the `WebClient` always throws a `ClassCastException`
when an error occurs in `bodyToMono(ParameterizedTypeReference)``, and
not the expected exception, as set up by `onStatus`
Issue: SPR-16025
Prior to this commit, asking for a `Void` type using any of the
`ClientResponse#bodyTo*` methods would immediately return an empty
`Publisher` without consuming the response body.
Not doing so can lead to HTTP connection pool inconsistencies and/or
memory leaks, since:
* a connection that still has a response body being written to it cannot
be properly recycled in the connection pool
* incoming `DataBuffer` might not be released
This commit detects when `Void` types are asked as body types and in
those cases does the following:
1. Subscribe to the response body `Publisher` to allow the connection to
be returned to the connection pool
2. `cancel()` the body `Publisher` if the response body is not empty; in
that case, we choose to close the connection vs. consume the whole
response body
Those changes imply that `ClientHttpResponse` and other related
contracts don't need a `close()` method anymore.
Issue: SPR-16018
Includes unified detection of Kotlin's optional parameters in MethodParameter.isOptional(), reduces BeanUtils.findPrimaryConstructor to Kotlin semantics (for reuse in AutowiredAnnotationBeanPostProcessor), and finally introduces a common KotlinDetector delegate with an isKotlinType(Class) check.
Issue: SPR-15877
Issue: SPR-16020
Prior to this issue, SPR-15920 added this new `close()` method which was
supposed to be called to clean resources after response processing.
This commit changes the meaning of that method: calling `close()` will
close the underlying HTTP connection. This has to be called if the
response body is not consumed by the application, since at that point
the underlying connection might be in an inconsistent state if shared in
a connection pool.
Issue: SPR-15993
This commit moves WebFluxUriComponentsBuilder.fromServerRequest to the
ServerRequest interface itself.
Consequently, the WebFluxUriComponentsBuilder is removes itself, as it
contained no other methods.
Issue: SPR-15953
The typical way to load DispatcherHandler is to use
WebHttpHandlerBuilder#applicationContext which also detecs filters,
exception handlers, as well as other beans that are injected into every
ServerWebExchange -- custom session manager, localecontext resolver,
codecs for form data, multipart data, etc
WebHttpHandlerBuilder is the preferred and way so removing the ones on
DispatcherHandler. They could always be added back later.
This commit introduces a visitor for router functions
(RouterFunctions.Visitor), allowing to iterate over all the components
that make up a router function.
This commit also introduces a ToStringVisitor, which creates a nicely
formatted string for use with toString().
Issue: SPR-15711, SPR-15711
This commit introduces the WebFluxUriComponentsBuilder, with a single
method that creates a UriComponentsBuilder for a ServerRequest. More
methods to be added by @rstoyanchev.
Issue: SPR-15953
This commit introduces a methodName() method to the ServerRequest,
returning the String name of the method. This method is useful for
non-standard HTTP methods.
Rossen Stoyanchev
Arjen Poutsma
Juergen Hoeller
Brian Clozel
Sebastien Deleuze
Jason Yu