Since type erasure can be fixed only when using
ParameterizedTypeReference based Java methods, RestOperations and
WebFlux API documentation should be updated to specify which extensions
are subject to type erasure, and which are not.
Issue: SPR-16273
This allows us to confirm 0.7.3 fixes and run tests against the latest
ahead of an upgrade to Reactor Netty 0.8 snapshots.
The fix for #231 and #240 are confirmed but unfortunately test case for
This commit moves the ResolvableType field from HttpEntity to
PublisherEntity, a new entity type defined in MultipartBodyBuilder.
With this change, the scope of the ResolvableType is limited to
multipart-related code, instead of becoming part of the complete
HttpEntity hierarchy.
Issue: SPR-16307
This commit adds new header assertions for `WebTestClient`.
`doesNotExist` tests that a given header is not present:
.expectHeader().doesNotExist("Cache-Control");
`contentTypeCompatibleWith` tests for MediaType compatibility:
.expectHeader().contentTypeCompatibleWith("text/*");
Issue: SPR-16285
This commit adds a ResolvableType field to HttpEntity, in order to
support Publishers as multipart data. Without the type, the
MultipartHttpMessageWriter does not know which delegate writer to use to
write the part.
Issue: SPR-16307
This commit allows CorsConfiguration#combine()
to differentiate permit default values set by
CorsConfiguration#applyPermitDefaultValues()
from values configured explicitly by the user.
Those permit default values will be overridden
by any user-provided ones while user-provided values
will be combined in an additive way, including
when "*" is specified.
Documentation has been improved accordingly.
Issue: SPR-15772
With this commit, the default content-type defined by the
view (usually "text/html;charset=UTF-8" defined in AbstractView)
is used if any, when none is defined in the response headers.
Issue: SPR-16247
This commit removes the mention that Spring Boot 2.0 includes
Jackson Kotlin module since it is not the case as of M7, and
add a note about using bean validation annotations with Kotlin.
If the response is set and we can't change the status through
ServerHttpResponse any more, allow the error signal to propagate and
let the individual server adapters handle it. Ultimately that should
result in closing the connection.
On Servlet containers, we check one last time if the response is
committed (we may not have filled the buffer). If not then save
the exception as a request attribute, dispatch, and re-throw it on the
container thread.
On Undertow access the connection and close it.
On Netty just let the error through to Reactor Netty.
Issue: SPR-16051