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
This commit further refines 240f254 to also support java.util.Optional
for synchronized cache access (i.e. when the `sync` attribute on
`@Cacheable` is set to `true`).
Issue: SPR-14853
This commit makes sure that the `unregister` order of registered
application contexts has no incidence on the removal of the LiveBeansView
MBean.
Rather than using the last application context's name to compute the
identity of the MBean to remove, the identity is stored when the MBean is
created.
This commit also adds missing tests.
Issue: SPR-14848