* GH-3183: Add ReactiveRequestHandlerAdvice
Fixes https://github.com/spring-projects/spring-integration/issues/3183
* Introduce a `ReactiveRequestHandlerAdvice` with a `BiFunction<Message<?>, Mono<?>, Publisher<?>>`
logic to apply a `Mono.transform()` operator for a returned from the handler `Mono` reply
* Fix `WebFluxRequestExecutingMessageHandler` to return a `Mono.then()` instead of an explicit subscription -
it happens downstream anyway during reply producing with a proper error handling, too
* Demonstrate `ReactiveRequestHandlerAdvice` in the `RSocketDslTests` - without `retry()` it fails
* Add `ConsumerEndpointSpec.customizeMonoReply()` for convenience
* Document `ReactiveRequestHandlerAdvice` feature
* * Fix language in docs
* GH-3155: Add support for Java DSL extensions
Fixes https://github.com/spring-projects/spring-integration/issues/3155
Provide an `IntegrationFlowExtension` for possible custom EI-operators
in the target project use-cases.
* * Move `IntegrationFlowExtension` tests ot its own test class
* Make all the `IntegrationComponentSpec` ctors as `protected` for possible custom extensions
* Make some `BaseIntegrationFlowDefinition` methods and properties as `protected` to get them
access from the `IntegrationFlowExtension` implementations
* Document the feature
* * Fix language and typos in docs
* * Add `protected` to one more `GatewayEndpointSpec` ctor
* Add JavaDocs to `GatewayEndpointSpec` methods
* * Add `protected` to one more `JmsPollableMessageChannelSpec` ctor
* GH-3154: Support `UriBuilderFactory.EncodingMode`
Fixes https://github.com/spring-projects/spring-integration/issues/3154
Spring Framework now provides a `DefaultUriBuilderFactory.EncodingMode`
for encoding URIs in the `RestTemplate` before and after uri template
enrichment with uri variables.
Therefore `encodeUri` and manual uri variables substitution is not necessary
in Spring Integration HTTP components
* Deprecate `AbstractHttpRequestExecutingMessageHandler.encodeUri` in favor of
`DefaultUriBuilderFactory.EncodingMode` and respective configuration
on the `RestTemplate` in HTTP module and `WebClient` in WebFlux module
* * Really populate `uriFactory` into an internal `RestTemplate`
* Ensure in tests that `encoding-mode` is populated properly into an internal `RestTemplate`
* Clean up affected HTTP tests for AssertJ and JUnit 5
* * Clean up formatting
* * Apply fix for WebFlux module
* Add docs for new `encoding-mode` option
* * Remove unused import in the test
Fixes https://github.com/spring-projects/spring-integration/issues/3132
It turns out that Checkstyle EmptyBlock doesn't complain about
empty default ctor.
Plus a new check for `super();` call treats it as a violation
* Remove `super();` from all the no-arg ctors
* Code style clean up in the affected classes according
IDEA suggestions
* Fix new Sonar smells
* Move `What's New` into `changes-5.1-5.2.adoc`
* Remove version from the `XSD` files:
1. Align with SF
2. The version for XSD doesn't matter for the current jar version,
since only the version is available in classpath is from the current
jar version
3. Modify `spring.schemas` to map all the possible versions for XSD
into the current one in a jar.
This way target applications can upgrade without changing the version
for XSD location and we don't need to require `versionless` variant
any more
4. The jar in classpath can handle only its own XSD, so independently
of version or no-version variants we still may fail because the current
jar may not support end-user code any more - need some fix over there
anyway.
* Remove `checkTestConfigs` Gradle task since we don't worry about XSD
version any more
* Modify `schemaZip` Gradle task to populate XSDs into a distribution
still with a version to avoid overriding on-line XSDs for version `1.0.x`.
We may consider not do that since SF doesn't and just bite a bullet
for always overriding those on-line XSDs to the actual one from the latest
release.
Fixes https://github.com/spring-projects/spring-integration/issues/3114
The contract of SpEL with its
`getValue(EvaluationContext context, @Nullable Object rootObject)` is
that we need to deal with provided `rootObject` even if it is `null`
and don't consult with `context.getRootObject()`
* Fix `ExpressionEvalMap` to have an internal `rootExplicitlySet`
to indicate that `root` explicitly provided by consumer, even if it is null.
According this flag call respective `Expression.getValue()`
* Add `@Nullable` to methods and their arguments into `ExpressionEvalMap`
& `FunctionExpression` to honor `Expression` contracts
* Populate an `HttpEntity` explicitly into `ExpressionEvalMap` from the
`HttpRequestHandlingEndpointSupport` and `WebFluxInboundEndpoint` for
full picture
* Fix JavaDocs indentations in the `ExpressionEvalMap`
Fixes https://github.com/spring-projects/spring-integration/issues/2987
To resolve XSD files properly from the classpath, their HTTPS reference
must be present in the `spring.schemas` to avoid the Internet interaction
for resolving an XSD file
**Cherry-pick to 5.1.x, 5.0.x & 4.3.x**
* Add Validation to HTTP Inbound
* Pull a validation functionality from `WebFluxInboundEndpoint` to its
super class `BaseHttpInboundEndpoint` making a validation available for
the `HttpRequestHandlingEndpointSupport` as well
* Do the same for the `validator()` option in DSL for the
`HttpInboundEndpointSupportSpec`
* Add `validator` XML attribute for both HTTP and WebFlux inbound
endpoint XSDs
* Test parsers for a new `validator` option
* Document validation in the `http.adoc`
* Apply some polishing in the `http.adoc`, as well as in the
`HttpRequestHandlingEndpointSupport` JavaDocs
* Clarify in `webflux.adoc` that validation is applied for the
`Publisher` items before the payload is finally built for the message to
send.
* Add WebFlux into the table of endpoints in the `endpoint-summary.adoc`
* * Remove unused imports
* Fix `SimpleMessageListenerContainerSpec` for deprecated `txSize` option
* Add validation support into WebFlux Inbound
See https://stackoverflow.com/questions/56729517/spring-integration-webflux-validate-input-json-body
* Introduce a `WebFluxInboundEndpoint.validator` option to validate
a request payload after conversion HTTP request into a `Publisher`
* Expose a `WebFluxInboundEndpointSpec.validator()` option
* Introduce a `IntegrationWebExchangeBindException` to extend a
`WebExchangeBindException` for Spring Integration use-case.
such an exception is used in the `ResponseStatusExceptionHandler`
extensions, like one in Spring Boot for proper response rendering
* Test and document the solution
* * Remove unused imports from IntegrationWebExchangeBindException
The recently introduced `setPublisherElementType()` and
`setPublisherElementTypeExpression()` in the
`WebFluxRequestExecutingMessageHandler` are missed in the
`WebFluxMessageHandlerSpec` as delegation options
* Add `@Nullable` for `WebClient` ctor arg in the
`WebFluxRequestExecutingMessageHandler`
* Add the support for a `Publisher`, `Resource` and `MultiValueMap`
into the `WebFluxRequestExecutingMessageHandler`
* Along side with the `WebFluxRequestExecutingMessageHandler.setPublisherElementType`
and `WebFluxRequestExecutingMessageHandler.setPublisherElementTypeExpression`,
add XSD support for the `publisher-element-type(-expression)`, which
is used for the element type when request body is a `Publisher`
* Polishing for `AbstractHttpRequestExecutingMessageHandler`
* Fix Sonar smells for affected classes
* Remove used imports
Doc polishing
* Do not fix urls for the `http://apache.org/xml/features` when we
configure XML components
* Do not fix urls for localhost and fake links in tests
* Fix all the dead links in docs
Fixes https://github.com/spring-projects/spring-integration/issues/2752
The logic in the `IntegrationRequestMappingHandlerMapping` fully depends
on the application context it has been registered with, therefore any
arbitrary `ContextRefreshedEvent` doesn't fit our requirements.
More over it may cause a problem with missed mappings when parent-child
configuration is used.
**Chery-pick to 5.1.x, 5.0.x & 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4479
For better user experience expose a `RequestEntity<?>` as a root object
for evaluation context for `statusCodeExpression` execution
JIRA: https://jira.spring.io/browse/INT-4436
* Fix `IntegrationRequestMappingHandlerMapping` and
`IntegrationRequestMappingHandlerMapping` to implement a
`DestructionAwareBeanPostProcessor` to allow to register and
destroy HTTP endpoints at runtime, e.g. via `IntegrationFlowContext`
with the dynamic `IntegrationFlow`s
* GH-2464: WebFlux: Get rid of Mono.block()
Fixes https://github.com/spring-projects/spring-integration/issues/2464
The `WebFluxInboundEndpoint` resolves a `Principal` via `Mono.block()`
operation.
This is prohibited situation in the non-blocking thread, like Reactor
Netty
* Defer `Mono<Principal>` resolution to the message header via
deferring the whole `Message` creating via `flatMap()` operation on the
main `doHandle()` `Mono`
**Cherry-pick to 5.0.x**
* * Fix Checkstyle for the Reactive Spring Security testing utils static imports
* Add `defaultIfEmpty()`, when `exchange.getPrincipal()` is an empty `Mono`
JIRA: https://jira.spring.io/browse/INT-4462
When the HTTP request body is empty, the `HttpMessageReader` ends up
with the empty `Mono` which can't be evaluated to any reasonable value.
* Add fallback to `requestParams` when `Mono` for body is empty and
also when `payloadExpression` returns null
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4392
JIRA: https://jira.spring.io/browse/INT-4391
JIRA: https://jira.spring.io/browse/INT-4393
Resolve class and leaf package tangles in:
- core (except DSL)
- file
- http
- move `StaticMessageHeaderAccessor` to root `integration` package
- move acknowledgment related classes to a new `acks` package
- move `MMIH` to `handler.support`, alongside argument resolvers, also `HandlerMethodArgumentResolversHolder`
- move `ErrorMessagePublisher` to `core`
- move `PatternMatchUtils` to `support.utils`
- move `MessageSourceManagement` to `support.management`
- remove direct reference to `MicrometerMetricsCapter` from `IntegrationManagementSupport`
- add new class `MetricsCaptorLoader`
- move `OperationsCallback` to inner interface in `RemoteFileOperations`
- move `HttpContextUtils` to `config`
* Simplify MetricsCaptor loading.
* Polishing
Fixes https://github.com/spring-projects/spring-integration/issues/2358
The WebFlux on the server side can deal with MVC `@Controllers` as well
without any Servlet environment.
* Enable `IntegrationGraphController` when we not only in the
Servlet environment, but also in the WebFlux
* Upgrade to SF-5.0.4 and fix WebFlux tests to meet the latest requirements
(https://jira.spring.io/browse/SPR-16337)
* Move `WEB_FLUX_PRESENT` to the `HttpContextUtils`;
deprecate it in the `WebFluxContextUtils`
* Mention WebFlux ability for the `IntegrationGraphController` in the
`graph.adoc`
* add `BodyExtractor` support for Outbound part
* add `ClientHttpResponseBodyExtractor` as identity function
* add XML configuration for the Inbound part
* document `BodyExtractor` and Inbound XML support
Rename `replyToFlux` property to the `replyPayloadToFlux`
Doc Polishing
Fixes: spring-projects/spring-integration#2300
To allow to consume a streaming HTTP response downstream expose
`replyToFlux` option on the `WebFluxRequestExecutingMessageHandler`.
This way the body of the HTTP response can be converted now to the
`Flux` for subsequent output message.
The option is `false` by default; can be changed to `true` in the `5.1`
JIRA: https://jira.spring.io/browse/INT-4350
Spring MVC and Spring WebFlux handles `ResponseEntity` via appropriate
`ReturnValue` handlers.
This way all the headers and status code are fully up to end-user.
The body is handled by the appropriate converter/writer as before
* Add `ResponseEntity` handling to the `HttpRequestHandlingMessagingGateway`
and `WebFluxInboundEndpoint`.
The logic mostly compy/pasted from the `ResponseEntityResultHandler`
JIRA: https://jira.spring.io/browse/INT-4358
* Parse response in the `WebFluxRequestExecutingMessageHandler`
in reactive, on demand manner.
* Add protected for empty response body in case of error
The `PollableChannelPublisherAdapter` is based on the poll model of the
`FluxSink` and iterate and poll downstream `PollableChannel` until
there is an item or `n > 0`.
Having `take(6)` we end up with the cancel from the downstream
`Subscriber` after the batch is filled, but at the same time we continue
to poll the upstream source because `n` is like `Long.MAX_VALUE`.
* The proper way to interact is check for the `!sink.isCancelled()`
as well.
This way cancelled `sink` won't "steal" data from other subscribers
Fix compatibility with the latest dependencies
* Upgrade to Gradle 4.1
* Upgrade as much dependencies as possible
* Fix MongoDB module to resolve deprecation in the latest driver
* Increase receive timeout in the `ResequencerTests`
* Restore generic argument for the method reference in the `ReactiveStreamsTests`
* Fix `WebFluxInboundEndpoint` for the compatibility with the latest Reactor API
JIRA: https://jira.spring.io/browse/INT-4315
Move Reactive components outside of HTTP module to the new WebFlux one,
including XSD, tests and documentation
Make an appropriate polishing for the `http.adoc` with cross-link
to the `webflux.adoc`
Exclude transitive `spring-webmvc` for the `spring-integration-webflux`
