This commit fixes the implementation of
ExtractingResponseErrorHandler.hasError to allow for null values,
indicating an override of the behavior inherited from
DefaultResponseErrorHandler.
Issue: SPR-15544
Defining nullability of some API like EnvironmentCapable
or ConditionContext causes issues in Spring Boot because
in the context where they are used, it is known for sure
they will return non-null values even if their API can in
other context return null values.
It is better in this case for both Java and Kotlin to
not define at all the nullabity of such API.
In practice, this is achieved by removing the package level
@NonNullApi annotation and adding it only on the
relevant classes.
Issue: SPR-15540
The change to "optimize" the template by not rebuilding the reply
message when the original header channels was null was incorrect.
We need to null out those headers if they were originally null.
Issue: SPR-15991
This commit makes Spring @Nullable annotation leveraging
JSR 305 @TypeQualifierNickname + @Nonnull(when= When.MAYBE)
instead of directly using @javax.annotation.Nullable which
seems not designed to be used as a meta-annotation.
It also removes @TypeQualifierDefault since the purpose of
this annotation when applied at method level is to only
change return value nullability, not parameters one.
Issue: SPR-15540
This commit replaces the UnaryOperatory<ServerWebExchange> inputs with
Function<ServerWebExchange, ServerWebExchange> instead. Unfortunately
the composability methods inherited from Function don't work in terms
of generics for composing multiple UnaryOperator's.
Issue: SPR-15599
Provide a mechanism to override the configured send and receive
timeouts in the GenericMessagingTemplate.
- overload `doReceive()` to take a receive timeout argument
- for `sendAndReceive()` methods examine message headers for these
timeout values
- remove headers to avoid propagation
- avoid the unconditional rebuild of the reply message if the
original headers weren't present
- also remove headers from simple `send()` operations
- change javadocs for the setters to indicate they are now defaults
- add properties to allow the user to override the header names used
- change `TemporaryReplyChannel` to use `send` arg and change to static
- add package-protected ctor to avoid the compiler creating a
synthetic constructor for access
Issue: SPR-15591
This commit introduces ExtractingResponseErrorHandler: an alternative
ResponseErrorHandler that uses `HttpMessageConverter`s to convert HTTP
error responses to `RestClientException`.
Issue: SPR-15544
Simplify the internals of the DefaultCodecs implementation favoring
explicit fields per override vs a generic list of readers and writers
for overrides.
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
As a follow-up to the recent commit 246e72 some slight modifications
to MockServerExchangeMutator (renamed to ExchnageMutatorWebFilter).
Aside from the name change, the main difference is that "per request"
exchange processors are now simply applied via WebTestClient#filter(..).
Issue: SPR-15570
This commit also changes "hibval5Version" to the more general "hibvalVersion" build variable, and includes dependency updates to Caffeine 2.5.1 and JRuby 9.1.9.
Issue: SPR-13482
This commit replaces the option to bind the WebTestClient to an
HttpHandler to bind to a WebHandler instead.
This allows testing below the WebFlux level such as WebFilter,
WebHandler, or WebSession scenarios, but still a level above
HttpHandler so that WebTestClient is in charge of creating the
ServerWebExchange and expose consistently the
WebTestClient#MockServerSpec setup across all "mock" server bindToXxx
options.
Issue: SPR-15570
This commit factors ServerWebExchange mutator support out of
WebTestClient in favor of an independent public class called
MockServerExchangeMutator which implements WebFilter and can be
applied to the WebTestClient as any other WebFilter.
The MockServerExchangeMutator also exposes a method to apply
a client-side filter for "per request" mutators. See the Javadoc
of the MockServerExchangeMutator.
Issue: SPR-15570
This commit introduces a new method in HttpRequest:
`String getMethodValue`, which returns the HTTP method as a String.
Furthermore, HttpRequest.getMethod() has been given a default
implementation using this String value in combination with
`HttpMethod.resolve`.
Issue: SPR-15545
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
Prior to this commit, resolving resources from webjars using the
`WebJarAssetLocator.getFullPath` could lead to multiple candidates,
since this method is trying to find *any* resource matching that path
under the given webjar location.
This commit replaces that call with
`WebJarAssetLocator.getFullPathExact`, which avoids those multiple
matches and only resolves resources if the given path is exact.
Issue: SPR-15526
(cherry picked from commit e2aa117ff9)
Arjen Poutsma
Rossen Stoyanchev
Christoph Dreis
Kazuki Shimizu
QBNemo
Sebastien Deleuze
Gary Russell
Stephane Nicoll
Sam Brannen
Stéphane Nicoll
Andy Wilkinson
Juergen Hoeller
Andy Clement
skarafaz