Since we have a dedicated section regarding Ehcache that is only
applicable to Ehcache 2.x, this commit clarifies that Ehcache 3.x is
JSR-107 compliant and the JCache support should be used with it
rather than attempting to configure the Ehcache 2.x support.
Commit 240f254 has introduced support for `java.util.Optional` in the
cache abstraction. If such type is present, the contained value is cached
if it is present.
This new feature slightly changed the semantic of `#result` that was
documented up till this commit as the "return value of the method
invocation". This is no longer true as `#result` for `Optional<T>`
refers to the `T` instance and not the `Optional` instance.
This commit clarifies both the javadoc and the documentation.
Issue: SPR-14587
Previously invoking HtmlUnitRequestBuilder merge caused the pathInfo of
the parent to be corrupted. This could additional invocations with the
same parent.
This fix ensures that the parent is no longer directly used. Instead,
we create a copy of the parent by merging the parent that was passed in
with the copy.
Fixes SPR-14584
reactor.test.TestSubscriber will not be part of Reactor Core
3.0.0 since it needs to be refactored to fit all the needs
expressed by the users. It is likely to be back later in one
of the Reactor Core 3.0.x releases.
This commit anticipate this removal by temporarily copying
TestSubscriber in spring-core test classes. As soon as
the new TestSubscriber will be available in Reactor Core,
Spring Framework reactive tests will use it again.
There is really no need for a result handler dedicated to a void
return value and it's actually problematic to have it.
Each result handler treats void as necessary. For an @ResponseBody
method it means an empty body. For view resolution it means no specific
value was returned and we should procede with selecting a default view
name. Having a dedicated void result handler can interfere with this
especially since view resolution needs to be last in order.
At the same time there are cases when no result handling is needed
and the response is fully handled within the HandlerAdapter. This is
the case with WebHandler and the SimpleHandlerAdapter. For that case
we simply return mono.then(aVoid -> Mono.empty()) which effectively
returns an empty Mono and no result handling follows. The
HandlerAdapter already says you can return no values at all if the
response is fully handled.