The method to access the Principal from the ServerWebExchange is now
a Mono<Principal> (rather than Optional<Principal>).
There is also support for Principal as a controller method argument.
Issue: SPR-14680, SPR-14865
This commit adds support for detecting the target WebHandler along with
WebFilters, WebExceptionHandlers, and other spring-web reactive
strategies in an ApplicationContext.
WebReactiveConfigurationSupport has @Bean factory methods for
DispatcherHandler and ResponseStatusExceptionHandler.
WebHttpHandlerBuilder has a static factory method that initializes the
builder from an ApplicationContext. This method is also used in the
DispatcherHandler#toHttpHandler(ApplicationContext) shortcut method.
Issue: SPR-14837
The createBinder method in BindingContext now returns the binder
instance rather than a Mono with the expectation that binder
initialization (e.g. @InitBinder) does not require blocking.
Issue: SPR-14543
HandlerMethodArgumentResolver is a non-blocking contract, however only
implementations that read the request body require blocking.
This commit introduces SyncMethodArgumentResolver as an extension of
the non-blocking contract that allows synchronous implementations to
use synchronous argument resolution.
There is also a SyncInvocableHandlerMethod extension that uses only
sync argument resolvers and allows a synchronous invocation.
Issue: SPR-14543
This commit introduces a couple of changes to BodyInserters:
- Refactored writeWithMessageWriters into BiFunction
- BodyInserters.fromResource now uses ResourceMessagewriter from context
- BodyInserters.fromServerSentEvents now uses SseHttpMessageWriter from context
Reactor recently added the `ScriptedSubscriber` in its new
`reactor-addons` module. This `Subscriber` revissits the previous
`TestSubscriber` with many improvements, including:
* scripting each expectation
* builder API that guides you until the final verification step
* virtual time support
This commit refactor all existing tests to use this new
infrastructure and removed the `TestSubscriber` implementation.
Issue: SPR-14800
This commit removes factory methods for `RequestMappingHandlerMapping`
and `RequestMappingHandlerAdapter` from `WebReactiveConfigurer`.
`WebReactiveConfigurer` should promote only common customizations;
those factory methods should be overridden when extending
`WebReactiveConfigurationSupport`, in advanced configuration scenarios.
This commit introduces support for running multiple HttpHandler's under
distinct context paths which effectively allows running multiple
applications on the same server. ContextPathIntegrationTests contains
an example of two applications with different context paths.
In order to support this the HttpHandler adapters for all supported
runtimes now have a common base class HttpHandlerAdapterSupport
which has two constructor choices -- one with a single HttpHandler and
another with a Map<String, HttpHandler>.
Note that in addition to the contextPath under which an HttpHandler is
configured there may also be a "native" contextPath under which the
native runtime adapter is configured (e.g. Servlet containers). In such
cases the contextPath is a combination of the native contextPath and
the contextPath assigned to the HttpHandler. See for example
HttpHandlerAdapterSupportTests.
Issue: SPR-14726
This commit adds a bodyToMono and bodyToFlux convenience method to
ClientResponse/ServerRequest, similar to the body(Publisher) method that
is on ClientRequest/ServerResponse.
This commit introduces the following changes to web.reactive.function:
- Added RouterFunction.andRoute(), a combination of RouterFunction.and()
with RouterFunctions.route()
- ServerRequest.pathVariable() returns String instead of
Optional<String>. An exception is thrown if the variable is not present.
- Added HandlerFilterFunction.andThen and HandlerFilterFunction.apply()
This commit removes the usage of Reactor adapters (about to
be moved from Reactor Core to a new Reactor Adapter module).
Instead, RxReactiveStreams is now used for adapting RxJava
1 and Flowable methods are used for RxJava 2.
Issue: SPR-14824
This commit changes web.reactive.function to reflect the introduction of
the new WebClient. Changes include:
- Request -> ServerRequest
- Response -> ServerResponse
- FilterFunction -> HandlerFilterFunction
- StrategiesSupplier -> HandlerStrategies
This commit refactors the web client to be more similar to
web.reactive.function. Changes include:
- Refactor ClientWebRequest to immutable ClientRequest with builder and
support for BodyInserters.
- Introduce ClientResponse which exposes headers, status, and support
for reading from the body with BodyExtractors.
- Removed ResponseErrorHandler, in favor of having a ClientResponse
with "error" status code (i.e. 4xx or 5xx). Also removed
WebClientException and subclasses.
- Refactored WebClientConfig to WebClientStrategies.
- Refactored ClientHttpRequestInterceptor to ExchangeFilterFunction.
- Removed ClientWebRequestPostProcessor in favor of
ExchangeFilterFunction, which allows for asynchronous execution.
Issue: SPR-14827
This commit moves the web.reactive.function.[BodyInserter|BodyExtractor]
to http.codec, so that they can be used from the client as well.
Furthermore, it parameterized both inserter and extractor over
ReactiveHttpOutputMessage and ReactiveHttpInputMessage respectively, so
that they can be limited to only be used on the client or server.
This commit improves the existing web reactive configuration
infrastructure with the following changes:
* renamed `WebReactiveConfiguration` to
`WebReactiveConfigurationSupport` and is is no longer a Configuration
class
* created the `WebReactiveConfigurer` interface; Configuration classes
implementing it will augment the web reactive configuration support
* created the `DelegatingWebReactiveConfiguration` and
`WebReactiveConfigurerComposite` to effectively tie those custom-defined
configurers to the main configuration support
* created the `@EnableWebReactive` to active that support in
configuration classes
Issue: SPR-14754
This commit replaces direct use of Validator and ConversionService in
the reactive @RequestMapping infrustructure in favor of using the
BindingContext.
Issue: SPR-14541
This commit adds a BindingContext to be used in spring-web-reactive
@RequestMapping infrastructure (comparable to WebDataBinderFactory in
spring-web-mvc) for access to the default model, data binding,
validation, and type conversion purposes.
Issue: SPR-14541
This is a port of Spring MVC CORS support for Spring Web Reactive:
- CORS classes keep the same name but are in the
web.cors.reactive package
- CorsConfiguration is reused because not tied to Servlet API
- CORS HandlerMapping integration is done at
AbstractHandlerMapping level
- AbstractUrlHandlerMapping and AbstractHandlerMethodMapping
have been slightly modified to call
AbstractHandlerMapping#processCorsRequest()
- Both global CORS configuration + @CrossOrigin support have
been implemented
Issue: SPR-14545
