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 the `DispatcherServletCustomizer` callback
interface that can be used to customize the `DispatcherServlet` that a
`MockMvc` is using.
Previously, only the `dispatchOptions` flag can be customized. This
commit allows to customize any property of `DispatcherServlet` before it
is initialized.
Issue: SPR-14277
The ServerWebExchange now has a getFormData() method that delegates to
FormHttpMessageReader for the parsing and then caches the result so
it may be used multiples times during request processing.
Issue: SPR-14541
This commit introduces two new `WebClient` methods: `retrieveMono` and
`retrieveFlux`, both of which offer direct access to the response body.
More importantly, these methods publish a WebClientException if the
response status code is in the 4xx or 5xx series.
Issue: SPR-14852
Prior to this commit, when using @EnabledIf or @DisabledIf in Spring's
JUnit Jupiter support, the test's ApplicationContext was always eagerly
loaded, even if the ApplicationContext would never be used (i.e., the
test was disabled). This behavior can lead to undesirable side effects
-- for example, attempting to load an application context that requires
services only available on the CI server when the test is not actually
running on the CI server.
This commit addresses this issue by introducing new boolean
`loadContext` flags in @EnabledIf and @DisabledIf. By default these
flags are set to false which means that the user's test application
context will not be loaded to evaluate the expression. On the contrary,
a dummy application context will be loaded instead, and expressions
will be evaluated against that dummy context. Consequently, if the user
wishes to interact with properties from the Spring Environment or with
beans from the test application context, the `loadContext` must be
explicitly set to true.
In addition, expressions which evaluate to a String must now evaluate
to exactly "true" or "false" (ignoring case and surrounding whitespace).
Issue: SPR-14649
Rossen Stoyanchev
Juergen Hoeller
Sebastien Deleuze
Stephane Nicoll
Sam Brannen
Arjen Poutsma