Since `PathPattern.combine` now returns another `PathPattern` instance
(it was previously returning a String instance), we can now safely
remove the parser instance included in `PatternsRequestCondition`.
Issue: SPR-15663
Use copy constructor to refresh a session with lastAccessTime and a
save function referencing the current exchange. As a result both fields
are now final and ConfigurableWebSession is no longer needed.
This commit introduces overloaded variants of `bodytoMono`,
`bodyToFlux`, `toEntity`, and `toEntityList` that take a
`ParameterizedTypeReference`. It also adds similar methods to
`WebClient.ResponseSpec`.
Issue: SPR-15725
This binary format more efficient than JSON should be useful for server
to server communication, for example in micro-services use cases.
Issue: SPR-15424
This commit introduces an apply method to `WebClient.Builder`, allowing
users to make multiple changes to the builder in one consumer.
Issue: SPR-15743
The failures look like older failures possibly exposed by recent
changes in Reactor.
The one in ViewResolutionResultHandler is very old test error.
The one in Jackson2JsonDecoderTests is more recent but went unreported.
This commit moves `toEntity(Class<T>)` and `toEntityList(Class<T>)`
from WebClient.ResponseSpec to ClientResponse. The main reason for doing
so is that the newly introduced `onStatus` method (see
2f9bd6e075) does not apply to these two
methods, and the result would be confusing. Also, `ClientResponse` and
`ResponseEntity` represent the same data: status code, headers, and a
body.
Issue: SPR-15724
This commit introduces a way to customize the WebClientExceptions, as
thrown by WebClient.ResponseSpec.bodyTo[Mono|Flux]. The first
customization will override the defaults, additional customizations are
simply tried in order.
Issue: SPR-15724
This commit changes `ServerRequest.attribute(String)`` to return
`Optional<Object>` instead of `Optional<T>`, where `T` was infered
from a type parameter.
This commit makes the `uri` step of the WebClient optional, so that
users who have specified a base URL during WebClient config do not need
to provide an empty one (i.e. `url("")`).
The basic idea of this fix is that the HTTP method methods in WebClient
(`get`, `post`, etc.) should be able to "bypass" the uri stage, and skip
straight to defining headers, or even doing an exchange or retrieve
(i.e. call methods on `RequestHeaderSpec` or `RequestBodySpec`).
I have accomplished this by adding two new composed interfaces:
`RequestHeadersUriSpec` and `RequestBodyUriSpec`.
`RequestHeadersUriSpec` extends from the existing `UriSpec` and
`RequestHeaderSpec`, while `RequestBodyUriSpec` extends from `UriSpec`
and `RequestBodySpec`. These types are returned from the HTTP methods
(`get`, `post` etc). The `uri` methods on these types return a plain
`RequestHeaderSpec` and `RequestBodySpec` (i.e. types without the `uri`
methods), so that you can call `uri` once only.
Issue: SPR-15695
Explicitly pass the client-side JSR-356 WebSocketContainer to the
TomcatWebSocketClient to prevent the ContainerProvider from finding
the one from undertow-websockets-jsr through the ServiceLoader API.
This commit disables the "failOnServerError" feature on the
`HttpClientRequest`, as wrapped by ReactorClientHttpRequest. 5xx errors
are supposed to be dealt with in the WebClient, not in the lower-level
components.
Issue: SPR-15739
This commit introduces client-side request attributes, similar to those
found on the server-side. The attributes can be used, for instance, for
passing on request-specific information to a globally registered
ExchangeFilterFunction.
The client request builder, as well as WebClient.RequestHeadersSpec and
WebTestClient.RequestHeaderSpec, add methods for adding a single
attribute, as well as manipulating the entire attributes map.
The client request itself adds a accessor for the (immutable) attributes
map.
This commit also introduces a new variant of the basic authentication
filter in ExchangeFilterFunctions. This variant takes the username and
password from well-known attributes.
Issue: SPR-15691
Previously `UrlBasedCorsConfigurationSource` was relying on
`PathMatcher` implementations for matching incoming request lookup paths
with the configured path patterns for CORS configuration.
This commit replaces the use of `PathMatcher` with a `PathPatternParser`
that parses the string patterns into `PathPattenr` instances and allows
for faster matching against lookup paths.
Issue: SPR-15688
This commit changes ServerRequest.queryParams from returning a
List<String> given a String name, to returning a
MultiValueMap<String, String>, which gives more flexibility.
This commit uses the newly introduced `PathContainer` and `RequestPath`
support in the functional web framework. It exposes the path container
as property in `ServerRequest`, and uses that in the path-based
`RequestPredicates`.
Direct comparison of a pattern (as a String) to the path does not make
much sense now that we deal with URL encoding through PathContainer
which exposes (safely) decoded path segments.
Removing the PathPatternComparator also means we can keep patterns
pre-sorted instead of sorting them all the time. That probably offsets
any benefits from comparing to the lookup path for direct matches and
patterns are still sorted according to specificity.
This commits extends nullability declarations to the field level, formalizing the interaction between methods and their underlying fields and therefore avoiding any nullability mismatch.
Issue: SPR-15720
This commit adds a new `cloneBuilder()` method on `WebClient.Builder`;
we can now reuse the customizations of an existing builder without
sharing its state across several `WebClient` building code paths.
Issue: SPR-15690
This commit introduces 2 new public methods in HttpHeaders in order
to leverage Java 8 ZonedDateTime in addition to the existing long
(with GMT time zone implied) variants:
- ZonedDateTime getFirstZonedDateTime(String headerName)
- void setZonedDateTime(String headerName, ZonedDateTime date)
This commit also leverages Java 8 thread-safe DateTimeFormatter for
HttpHeader implementation instead of SimpleDateFormat. As a consequence
of the usage of DateTimeFormatter.RFC_1123_DATE_TIME, HTTP date header
serialization could change slightly for single digit days from for
example "Thu, 01 Jan 1970 00:00:00 GMT" to
"Thu, 1 Jan 1970 00:00:00 GMT".
Issue: SPR-15661
This commit adds support for Void response body types in the WebClient,
both when using `exchange` with a response.bodyToMono(Void.class), as
well as using `retrieve` with `toEntity(Void.class)`.
Issue: SPR-15679
This commit replaces the WebClient.filter method with
WebClient.Builder.filter. The reason for this change is that filters
added via WebClient.filter would be applied in the opposite order of
their declaration, due to the compositional nature of the method,
combined with the immutable nature of the WebClient.
WebClient.Builder.filter does keep the order of the filters, as
registered.
Furthermore, this commit introduces a WebClient.mutate() method,
returning a WebClient.Builder. This method allow to add/remove filters
and other defaults from a given WebClient.
Issue: SPR-15657
Add WebClient.Builder.addFilter
Add Consumer-based headers and cookies methods to builders.
Add WebClient.mutate
This commit changes the `ExchangeStrategies` and `HandlerStrategies`
interfaces to consistently use the `CodecConfigurer` (and
sub-interfaces) for configuring codecs on the server and on the client.
Issue: SPR-15682
Supporting ScriptEngine#eval(String, Bindings) when no render function
is specified allows to support use cases where script templates are
simply evaluating a script expression with an even more simplified
configuration.
This improvement also makes it possible to use script engines that
do not implement Invocable.
Issue: SPR-15115
This commit introduces LocaleContextResolver interface, which is used
at ServerWebExchange level to resolve Locale, TimeZone and other i18n
related informations.
It follows Spring MVC locale resolution patterns with a few differences:
- Only LocaleContextResolver is supported since LocaleResolver is less
flexible
- Support is implemented in the org.springframework.web.server.i18n
package of spring-web module rather than in spring-webflux in order
to be able to leverage it at ServerWebExchange level
2 implementations are provided:
- FixedLocaleContextResolver
- AcceptHeaderLocaleContextResolver
It can be configured with both functional or annotation-based APIs.
Issue: SPR-15036
Previously `HandlerMapping` implementation were heavily relying on
`String` path patterns, `PathMatcher` implementations and dedicated maps
for matching incoming request URL to an actual request handler.
This commit adds the `PathPatternRegistry` that holds `PathPattern`
instances and the associated request handler — matching results are then
shared as `PathMatchResult` instances. `AbstractUrlHandlerMapping` will
use this registry directly, but other components dealing with request
matching (like `PatternsRequestCondition`) will directly use ordered
`PathPattern` collections since ordering is important there.
This opens the door for faster request matching and simplifies the
design of this part.
Issue: SPR-15608
This commit removes the headers(HttpHeaders) method on ClientRequest and
ServerResponse, in favor of headers(Consumer<HttpHeaders>), which is
more flexible.
The revised builder emphasizes creating a list of resolvers either
built-in or custom with each top-level builder method resulting in
adding a resolver.
By default only the Header resolver is configured.
The path extension resolver is removed altogether to discourage its use
but is trivial to create manually with the helpf of
UriUtils#extractFileExtension + MediaTypeFactory.
Issue: SPR-15639
After the removal of suffix pattern matches, there is no longer a need
to expose the list of registered file extensions.
Also polish, refactor, and simplify the abstract base class
AbstractMappingContentTypeResolver and its sub-classes.
Issue: SPR-15639
There is no need for ResourceWebHandler to go through the
PathExtensionContentTypeResolver when MediaTypeFactory makes it easy to
perform such lookups for a given Resource.
This does not support any extensions explicitly registered through a
WebFluxConfigurer but it would be easy enough to pass those into
ResourceWebHandler as a simple Map<String, MediaType>, should the need
arise.
Issue: SPR-15639
The use of the undecoded URL path by default and the removal of suffix
pattern matching effectively means HttpRequestPathHelper is no longer
needed.
Issue: SPR-15640, SPR-15639
Introduce pathWithinApplication() in ServerHttpRequest and use it for
request mapping purposes instead of LookupPath.
In turn this means that for request mapping purposes:
1) the path is not decoded
2) suffix pattern matching is not supported
Issue: SPR-15640
This commit changes the use of `ResolvableType` to
`ParameterizedTypeReference` in all public-facing WebFlux APIs. This
change removes the necessity for providing the parameterized type
information twice: once for creating the `ResolvableType`, and once for
specifying a `BodyExtractor`.
Issue: SPR-15636
This commit also removes nullability from two common spots: ResolvableType.getType() and TargetSource.getTarget(), both of which are never effectively null with any regular implementation. For such scenarios, a non-null empty type/target is the cleaner contract.
Issue: SPR-15540
This commit adds two Consumer based methods to ClientRequest that allow
for direct manipulation of the underlying headers or cookies map. As
such, these methods can be used to override or remove existing entries.
Issue: SPR-15635
This commit changes the `headers(HttpHeaders)` method in
DefaultClientRequestBuilder so that it copies the individual header
values instead of using the `List<String>` value directly. The reason
for this change is that the list of values can be immutable, and adding
additional values after that could result in
UnsupportedOperationExceptions.
Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.
Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.
Issue: SPR-15540
Restore matrix variable parsing code not resorting to the use of
WebUtils which brings Servlet API dependencies with it.
Instead the parsing logic is now exposed through HttpRequestPathHelper
which already contained the decoding logic and also the knowledge of
whether to decode the parsed variables or not.
Issue: SPR-15397
This commit adds the `LookupPath` class that contains the full
request path relative to the web context; the application can
get from it various information, including the file extension
and path parameters (if any).
Since that operation is done multiple times for each request, this
object is stored as an attribute at the `ServerWebExchange` level.
Issue: SPR-15397
With the new `ParsingPathMatcher` implementation, new patterns are now
allowed, such as `"/foo/{*bar}". The `"{*bar}"` segment will capture
everything until the end of the given path. Adding other elements after
that segment is illegal and will throw exceptions.
One can configure on a `PathMatchConfigurer` various options like
`useTrailingSlashMatch` and `useSuffixPatternMatch`; those options, when
enabled, will try to append suffixes like `".*"` and `"/"` to existing
path patterns. In case of a "capture the rest" pattern segment, those
options won't be honored.
This is why this commit ensures that an exception is thrown at the start
of the application if an illegal configuration is applied to the
`PathMatchConfigurer`.
Issue: SPR-15303, SPR-15558
This commit introduces 2 new @Nullable and @NonNullApi
annotations that leverage JSR 305 (dormant but available via
Findbugs jsr305 dependency and already used by libraries
like OkHttp) meta-annotations to specify explicitly
null-safety of Spring Framework parameters and return values.
In order to avoid adding too much annotations, the
default is set at package level with @NonNullApi and
@Nullable annotations are added when needed at parameter or
return value level. These annotations are intended to be used
on Spring Framework itself but also by other Spring projects.
@Nullable annotations have been introduced based on Javadoc
and search of patterns like "return null;". It is expected that
nullability of Spring Framework API will be polished with
complementary commits.
In practice, this will make the whole Spring Framework API
null-safe for Kotlin projects (when KT-10942 will be fixed)
since Kotlin will be able to leverage these annotations to
know if a parameter or a return value is nullable or not. But
this is also useful for Java developers as well since IntelliJ
IDEA, for example, also understands these annotations to
generate warnings when unsafe nullable usages are detected.
Issue: SPR-15540
This commit changes all methods that return `Supplier<Stream<T>` to
return `List<T>` instead. This includes the HandlerStrategies, but also
BodyInserter.Context, BodyExtractor.Context, and ServerResponse.Context.
The reason for this change is that most of the strategies have some sort
of order, where more specific message readers - for instance - come
before generic ones. Such an ordering can only be enforced through a
List.
Issue: SPR-15578
This commit removes the RouterFunctions.toHandlerMapping method, in
favor of native support for RouterFunctions in @EnableWebFlux
configuration classes.
In order to accomplish this, the HandlerStrategies components has been
repurposed to only be used for the "bare-bones" HttpHandler, while the
(newly introduced) RouterFunctionMapping uses the strategies as exposed
through WebFluxConfigurationSupport.
Furthermore, this commit also introduces support for testing
RouterFunctions without resorting to an application context.
Issue: SPR-15536
This commit adds support for configuring `WebFilter` and
`WebExceptionHandler` instances in HandlerStrategies. It also drops the
"native" support for `ResponseStatusException`s, in favor of the
`ResponseStatusExceptionHandler`, which is registered by default.
Issue: SPR-15518
The ResourceHandlerFunction now returns an `EntityResponse<Resource>`
(instead of a `ServerResponse`), so that filters can inspect/change the
returned Resource.
Starting with removing a package cycle on the use of
ResponseStatusException in the codec package, this commit generally
refines codec exception handling.
The new [Encoding|Decoding]Exception mirror the existing
HttpMessageNot[Readable|Writable]Exception and are used similarly
especially to differentiate betwen 400 and 500 errors when parsing
server request body content.
The commit also aligns some of the exception handling of JSON and XML
on the WebFlux side with that on the Spring MVC side.
Issue: SPR-15516
This commit turns the Synchronoss NIO Multipart HttpMessageReader into
a reader of Flux<Part> and creates a separate reader that aggregates
the parts into a MultiValueMap<String, Part>.
Issue: SPR-14546
With this commit, ServerCodecConfigurer is now exposed as a bean in
order to be provided to DefaultServerWebExchange via
WebHttpHandlerBuilder and HttpWebHandlerAdapter. This allows
DefaultServerWebExchange to get configured codecs for reading form or
multipart requests.
Issue: SPR-14546
This commit changes the handling of 4xx/5xx status codes in the
WebClient to the following simple rule: if there is no way for the user
to get the response status code, then a WebClientException is returned.
If there is a way to get to the status code, then we do not return an
exception.
Issue: SPR-15486
This commit renames `WebClient.ResponseSpec.bodyToEntity` to `toEntity`
and similarly renames `WebClient.ResponseSpec.bodyToEntityList` to
`toEntityList`. In both cases, the `body` prefix was dropped because the
return value contains more than the body.
Issue: SPR-15486
This commit renames the `body(Object)` on ServerResponse to
`syncBody(Object)`. The reason for this is that the original method
name clashed with the `body(Publisher)` method in the Kotlin extension.
The new name nicely reflects the synchronous nature of the method,
making it less appealing than the `Publisher`-based `body` method.
Issue: SPR-15467
This method introduces a new body(Object) to ServerResponse, a shortcut
to body(BodyInserters.fromObject(Object)).
Note that in the implementation of the method, an `instanceof` check is
performed to make sure that the passed argument is not a `Publisher`,
as users should call `body(Publisher, Class)` for sending a reactive
type.
This Publisher-check is also done in the `WebClient`, for the same
reasons.
Issue: SPR-15461
Without this change it was necessary to call getPathRemaining and
then chop up the path and make a call to matchAndExtract to get the
bound variables for the path part that matched. With this change
this is all done in the call to getPathRemaining which returns
an object holding the remaining path and the bound variables.
Issue: SPR-15419
This commit changes the `HandlerStrategies` and `ExchangeStrategies`
builders to use the `CodecConfigurer` for configuring Decoder|Encoder
and HttpMessage[Reader|Writer]. Other classes that use `CodecConfigurer`
have also been changed to reflect the refactoring to interfaces.
This commit also removes the ExchangeStrategies methods that take an
application context, as it was too naive approach to simply look up
every message reader and writer in the context.
Issue: SPR-15415, SPR-15435
This commit changes the `HandlerStrategies` builder to use
`ServerCodecConfigurer` for configuring Decoder|Encoder and
HttpMessage[Reader|Writer]. Note that the configurer is not exposed
directly, but wrapped so that `HandlerStrategies` can keep on returning
`this` for a proper builder pattern.
This commit also removes the HandlerStrategies methods that take an
application context, as it was too naive approach to simply look up
every message reader and writer in the context.
Issue: SPR-15415
- Renamed `defaultCodec` to `defaultCodecs`, and `customCodec` to
`customCodecs`
- Added `@Override` annotations where necessary
- Fixed non-parameterized usage for parameterized types.
This commit makes CodecException handling consistent between functional
and annotation-based APIs. It now returns by default 4xx status code
for decoding error and 5xx for encoding error + print the error reason
in logs without the full stack trace in both variants.
Issue: SPR-15355
The java.util.Optional wrapper should not affect the support for
"request param" arguments with or without the annotation as it
works on the Spring MVC side.
This commit uses the newly introduced
`PathPattern.getPathRemaining(String)` in the functional web framework.
With this change, all path predicates can be used for nested router
functions, so the `pathPrefix` predicate is no longer required and has
been removed.
Issue: SPR-15336
This commit introduces support for the server-side methods on
HttpMessageReader and HttpMessageWriter. It does so by introducing an
Optional ServerHttpRequest in BodyInserter.Context, and an Optional
ServerHttpResponse in BodyExtractor.Context. On the client-side, these
optionals return Optional.empty(); on the server-side, they return the
respective server-side messages.
Issue: SPR-15370
This change allows the functional WebFlux API to support natively
reactive types and also makes it possible for View implementations to
disable async attributes resolution if they want for example take
advantage of stream rendering.
It also makes AbstractView#getModelAttributes() asynchronous.
Issue: SPR-15368
Replace the overloaded "retrieve" methods with a single retrieve() +
ResponseSpec exposing shortcut methods (bodyToMono, bodyToFlux)
mirroring the ClientResponse shortcuts it delegates to.
Unlike exchange() however with retrieve() there is no access to other
parts of ClientResponse so ResponseSpec exposes additional shortcuts
for obtain ResponseEntity<T> or ResponseEntity<List<T>>.
Issue: SPR-15294
This commit makes a change to WebClient in oder to facilitate getting
the response body as a `Mono<Object>` or `Flux<Object>` without having
to deal with `ClientResponse`.
Specifically, this commit:
- Adds `RequestHeaderSpec.retrieve` methods, next to `exchange`, that
return the response body (and not a `ClientResponse`). Two convenience
methods return the response body as `Mono` or `Flux`.
- Adds ClientResponse.toRequestEntity to convert the ClientResponse
into a RequestEntity.
Issue: SPR-15294
The ServerCodecConfigurer is now passed all the way into the
RequestMappingHandlerAdapter which automatically enables the same
defaults even without the Java config and provides extra flexibility
in passing message codec configuration for the future.
This commit makes changes to WebClient and WebTestClient in oder to
limit setting the body according to HTTP method and also to facilitate
providing the request body as Object.
Specifically, this commit:
- Moves methods that operate on the request body to a RequestBodySpec
in both WebClient and WebTestClient, and rename them to `body`.
These methods now just *set* the body, without performing
an exchange (which now requires an explicit exchange call).
- Parameterizes UriSpec in both WebClient and WebTestClient, so that
it returns either a RequestHeadersSpec or a RequestBodySpec.
Issue: SPR-15394
Extract controller method caches including associated code and
discovery of @ControllerAdvice components into a separate, package
private helper class (ControllerMethodResolver).
This commit folds ServerHttpMessage[Reader|Writer] into its parent
HttpMessage[Reader|Writer] with the server methods pre-implemented
by default to be simple pass-through delegates.
This commit changes `ResourceTransformerSupport` to look for the
`ResourceUrlProvider` in the current request if none is configured on
the resource transformer itself.
Issue: SPR-15369
Prior to this commit, the `VersionResourceResolver` implementations of
`resolveUrlPathInternal` would delegate to the resolver chain but would
never use the give result if the current request didn't match a
configured version strategy pattern.
This is a problem if the resolver supposed to resolve the resource path
is configured after a `VersionResourceResolver` in the resolver chain;
this means that other resolver never gets to participate in the result
of the chain.
Issue: SPR-15372
Includes a new overloaded ModelAndView constructor with an HttpStatus argument, as well as a HandlerMethodArgumentResolverSupport refactoring (revised checkParameterType signature, actually implementing the HandlerMethodArgumentResolver interface).
Issue: SPR-15199
Follow-up to:
3d68c496f1
StringDecoder can be created in text-only vs "*/*" mode which in turn
allows a more intuitive order of client side decoders, e.g. SSE does
not have to be ahead of StringDecoder.
The commit also explicitly disables String from the supported types in
Jackson2Decoder leaving it to the StringDecoder in "*/*" mode which
comes after. This does not change the current arrangement since the
the StringDecoder ahead having "*/*" picks up JSON content just the
same.
From a broader perspective this change allows any decoder to deal with
String if it wants to after examining the content type be it the SSE
or another, custom decoder. For Jackson there is very little value in
decoding to String which works only if the output contains a single
JSON string but will fail to parse anything else (JSON object/array)
while StringDecoder in "*/*" mode will not fail.
Issue: SPR-15374
This commit introduces a `useRegisteredExtensionsOnly` property that
indicates whether classes that use the `MediaTypeFactory` for supplying
default media types can do so.
- In classes that were introduced in Spring 5.0, the
`useRegisteredExtensionsOnly` property takes the place of the
`useJaf` property that was removed in 0aaa652
- In classes that existed before Spring 5.0, the
`useRegisteredExtensionsOnly` property is added in addition to the
deprecated `useJaf`, the latter delegating to the former, but with
flipped behavior.
Issue: SPR-14908
This commit changes the `MediaTypeFactory` to return
`Optional<MediaType>` (instead of a plain `MediaType`) for the
`getMediaType` methods.
Issue: SPR-14908
CharSequenceEncoder now supports all MIME types, however since encoding
Flux<String> can overlap with other encoders (e.g. SSE) there are now
two ways to create a CharSequenceEncoder -- with support for text/plain
only or with support for any MIME type.
In WebFlux configuration we insert one CharSequenceEncoder for
text/plain (as we have so far) and a second instance with support for
any MIME type at the very end.
Issue: SPR-15374
This commit changes `ServerResponse` and subtypes to use properties
instead of fields during response rendering. This allows for overriding
these methods in a response subclass.
This commit changes the `HandlerFilterFunction.ofResponseProcessor`
method signature to return `Mono<ServerResponse>`, to better cooperate
with response builders (which all return a `Mono`).
Instead of accepting List<Encoder|Decoder> and then look for the first
to support JSON, always expect a single JSON [Encoder|Decoder] and use
that unconditionally.
When writing use the nested ResolvableType instead of the Class of the
actual value which should better support generics.
Remove the SSE hint and pass "text/event-stream" as the media type
instead to serve as a hint. We are expecting a JSON encoder and using
it unconditionally in any case so this should be good enough.
Consolidate JsonView hint extraction in shared base class.
Rename base class from AbstractJackson2Codec to Jackson2CodecSupport
since the class mainly provides support methods.
ServerHttpMessage[Reader|Writer] are now expected for WebFlux,
annotated controller endpoint and subsequently the instanceof checks
for HttpMessage[Reader|Writer] vs ServerHttpMessage[Reader|Writer] can
be removed from AbstractMessageReaderArgumentResolver and
AbtractMessageWriterResultHandler.
Support for flushing in EncoderHttpMessageWriter is now driven from a
configurable list of "streaming" media types with the list including
"application/stream+json" by default.
As a result Jackson2ServerHttpMessageWriter is no longer needed.
ServerHttpEncoder and ServerHttpDecoder are HTTP-specific
specializations that can prepare encoding and decoding hints from
extra information available on the server side.
As a result Jackson2ServerHttpMessageReader is no longer needed.
There is a natural way to implement ServerHttpMessage[Reader|Writer]
from [Encoder|Decoder]HttpMessageWriter by resolving hints first via
a protected method and then delegating to the regular read or write.
There is no downside either since it does not prevent
[Encoder|Decoder]HttpMessageWriter from being used for both client and
server scenarios while they're more useful.
As a positive side effect AbstractServerHttpMessage[Reader|Writer] can
be removed further simplfications can be made (in a future commit) to
accept ServerHttpMessageWriter for configuration purposes on the server
side and remove instanceof checks for ServerHttpMessageWriter.
This commit updates the main code base to conform to the dropped JAF
dependency in MediaTypeFactory. Specifically, it
- Removes JAF detection (JAF_PRESENT constants)
- Deprecated useJaf properties, with no direct replacement.
- Updated docs to remove JAF references, in favor of MediaTypeFactory.
Issue: SPR-14908
Fold ResourceRegionHttpMessageWriter into ResourceHttpMessageWriter.
The latter was a private helper (not meant to be exposed) and the two
have much in common now sharing a number of private helper methods.
The combined class does not extend AbstractServerHttpMessageConverter
from which it was not using anything.
Internally the combined class now delegates directly to ResourceEncoder
or ResourceRegionEncoder as needed. The former is no longer wrapped
with EncoderHttpMessageWriter which is not required since "resource"
MediaType determination is a bit different.
The consolidation makes it easy to see the entire algorithm in one
place especially for server side rendering (and HTTP ranges). It
also allows for consistent determination of the "resource" MediaType
via MediaTypeFactory for all use cases.
ResourceRegionHttpMessageWriter no longer extends from
EncoderHttpMessageWriter freeing it to pass the correct content type
into the encoder.
Considering that the main benefit of EncoderHttpMessageWriter is to
deal with content type fallback cases, there is nothing to be missed.
Furthermore ResourceRegionHttpMessageWriter is a package private class
that is used internally within ResourceHttpMessageWriter and never
exposed externally as a an actual HttpMessageWriter.
Issue: SPR-15358
CompositeHttpHandler is public and called ContextPathCompositeHandler.
Also an overhaul of the Javadoc on HttpHandler, WebHttpHandlerAdapter,
and ContextPathCompositeHandler.
Switch from extension to delegation model, i.e. delegating to
InvocableHandlerMethod, so that only sync invocation is exposed and
only resolvers of type SyncHandlerMethodArgumentResolver are allowed
to be configured in a cleaner fashion.
Currently the BOM versions are:
* reactor-core 3.0.6.BUILD-SNAPSHOT
* reactor-netty 0.6.2.BUILD-SNAPSHOT
This commit fixes as well a few deprecations in reactor-core.
From spring-webflux to spring-web test sources since it is perfectly
usable for testing Spring MVC annotation method support.
Potentially to be promoted further up for use in any module that has
annotation method support. It has spring-core dependencies only
In preparation for SPR-15132.
Turn the BindingContextFactory into ModelInitializer (both package
private) since creating BindingContext itself is quite simple.
The ModelInitializer also has only one field and no need to be aware
of fields the RequestMappingHandlerAdapter.
Brian Clozel
Rossen Stoyanchev
Arjen Poutsma
Sebastien Deleuze
Juergen Hoeller
Violeta Georgieva
Stephane Maldini
Stephane Nicoll
diguage
Kazuki Shimizu
Jon Borenstein
Andy Clement
Amey Jadiye
Sam Brannen