* Remove Boon dependency and its usage
* Remove overloaded methods from the `IntegrationFlowDefinition`
- we can simply rely now on the super class
* Remove (or rework) deprecated entities in the docs
* Fix tests for removed deprecated APIs
* Rework affected tests to JUnit 5
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.
* Introduce RSocketInteractionModel
* Deprecate `RSocketOutboundGateway.Command` in favor of newly introduced
top level `RSocketInteractionModel`
* Deprecate setter, DSL and XML configurations for the deprecated
`RSocketOutboundGateway.Command` in favor of newly introduced configurators
for the mentioned `RSocketInteractionModel`
* Add `IntegrationRSocketEndpoint.getInteractionModels()` contract for
inbound endpoints.
This way we can restrict mapped endpoints to the particular interaction
model(s)
* Add DSL and XML configuration for inbound interaction model option
* Document changes
* * Rebased into master; fix conflicts
* Fix consistency for `RetrieveSpec` in the `RSocketOutboundGateway`
and `rsocket.adoc`
* * Fix language in JavaDos and XSD attributes
Related to https://github.com/spring-projects/spring-framework/issues/23999
* Since Spring Integration inbound endpoints are generic in their method
signature we can't rely on a new `EMPTY_CONDITION` because it turns on
configuration merge into just `FrameType.REQUEST_FNF` &
`FrameType.REQUEST_RESPONSE`.
So, use `FrameType.REQUEST_FNF`, `FrameType.REQUEST_RESPONSE`,
`FrameType.REQUEST_STREAM` & `FrameType.REQUEST_CHANNEL` explicitly to
cover all the valid request-response models for SI endpoints
* Rework `RSocketOutboundGatewayIntegrationTests` according new logic.
Plus refactor to earlier subscription into `FluxMessageChannel` to
avoid potential race conditions
Related to: https://github.com/spring-projects/spring-boot/issues/18812
* Extract `ServerRSocketMessageHandler` into a `public` class to allow
to configure it as top-level bean and bind it into an existing server
* Change `ServerRSocketConnector` to accept the mentioned external bean
and don't create an internal RSocket server with an assumption that it
is create externally
* Add `IntegrationRSocketMessageHandler.requestMappingCompatible`
option to allow to configure `ServerRSocketMessageHandler` for both
Spring Integration RSocket channel adapters and regular `@MessageMapping`.
This is useful for Spring Boot auto-configuration
These changes give a hook to auto-configure Spring Integration RSocket
channel adapters in Spring Boot
* Fix some typos in `webflux.adoc` and `dsl.adoc`
* Make `FunctionsTests.kt` more Kotlin friendly
* Improve RSocket components and tests for them,
especially rely on the default `RSocketStrategies` in the
target SF RSocket components
* Rework `ServerRSocketConnector.setClientRSocketKeyStrategy` to use the whole `MessageHeaders` for consultation.
It turns out that just destination is not enough since it can be used from different clients
* Make the key based on the provided `setupData` by default
* Include all the `MessageHeaders` into the `RSocketConnectedEvent`
* Improve Docs according review feedback and Docs in SF
Doc polishing
* Use convenient `Consumer` API to avoid external iteration for
`setupMetadata` in the `ClientRSocketConnector`
* Add `routeVars` and `metadata` support into the `RSocketOutboundGateway`
* Cover new options in the XML and Java DSL configurations
Related to https://github.com/spring-projects/spring-framework/issues/23137
The metadata in Spring Messaging for RSockets now supports any
arbitrary objects for setup payload, including composition.
* Switch the `ClientRSocketConnector` to fully delegate to the
`RSocketRequester.Builder` inheriting possible metadata encoding/decoding
in the target `RSocketRequester` implementation
* Turn off a default `dataMimeType` from the `MimeTypeUtils.TEXT_PLAIN`
to the `null` by default relying on the encoder/decoder logic in the
target RSocket wrappers
* Expose more delegating options in the `ClientRSocketConnector`, like
`setupRouteVars`, `setupMetadata`
* Upgrade to RSocket API `1.0.0-RC3-SNAPSHOT`
* Use the same `rSocketMessageHandler.responder()` callback
for client and server rsocket factories configuration
* Clean up `ClientRSocketConnector` and `ServerRSocketConnector`
JavaDocs not mentioning overriding any more
* Use `WellKnownMimeType.MESSAGE_RSOCKET_COMPOSITE_METADATA` constant
instead of built-in literal
* Fix `RSocketOutboundGatewayIntegrationTests` according the SF changes
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**
* After introduction an `rsocketFrameType` header in the message,
we don't need a custom `IntegrationRSocket` any more.
Fully rely on the `MessagingRSocket` from the Spring Messaging, only
handle properly a `RSocketFrameTypeMessageCondition.CONNECT_CONDITION`
for connections from clients to emit an `RSocketConnectedEvent`
* Copy a `ChannelSendOperator` from the Spring Messaging for the proper
reply handling, when we are interested in the source `Publisher`
subscription first.
See its JavaDocs for more info
* Reusing already `public PayloadUtils` instead of its method copies
* Add support for the `MetadataExtractor` in the
`AbstractRSocketConnector`, `IntegrationRSocketMessageHandler`
and `IntegrationRSocket` for more flexible RSocket metadata
* Use `DefaultMetadataExtractor` in the
`IntegrationRSocketMessageHandler.afterPropertiesSet()` since the getter
is not available on the super class yet
* Use a `MetadataExtractor` in the `IntegrationRSocket` instead of an
old `CompositeMetadata` manipulation
* Use `PayloadUtils.retainDataAndReleasePayload()` since it is `public`
already
* Downgrade to the `rsocketVersion = '0.12.2-RC4'` since it looks like
the latest `1.0.0-RC1-SNAPSHOT` doesn't parse a frame properly on the
server side
When RSocket client connects to the server there is no reason to wrap
a `ConnectionSetupPayload` into a `Message` since we are not going to
send it downstream
* Refactor `IntegrationRSocket.handleConnectionSetupPayload()` just
return a `Mono<DataBuffer>` for converted `ConnectionSetupPayload`
* Ask for a `destination` and `RSocketRequester` from the
`IntegrationRSocket` instead of message headers
* Add `RSocketInboundGateway`; refactoring
* Extract an `AbstractRSocketConnector` for common client and server connectors logic
* Introduce an `IntegrationRSocketAcceptor` and `IntegrationRSocket` for the
mapping and handling logic of RSockets and messages in between
* Introduce an `IntegrationRSocketEndpoint` marker interface for Inbound Gateway mappings
* Add `RSocketInboundGateway` implementation, which is called from the
`IntegrationRSocketAcceptor` by the `IntegrationRSocketEndpoint` mapping
* Add `RSocketConnectedEvent` to emit when the client is connected to the server.
It does not make sense in Spring Integration to delegate such a logic into the
`RSocketInboundGateway`
* * Add `ServerRSocketConnector` to represent an RSocket server and
container for connected `RSocketRequester`s from clients
* Extract `accept(ConnectionSetupPayload setupPayload, RSocket sendingRSocket)`
server logic into an internal `ServerRSocketAcceptor` extension for the
`IntegrationRSocketAcceptor`
* Address PR comments:
- `RSocketConnectedEvent.toString()`
- `ApplicationEventPublisherAware` into the `ServerRSocketConnector`
- Log RSocket connection if no `this.applicationEventPublisher`
* Remove `handleConnectionSetupPayload()` from the `IntegrationRSocket`
since it is not delegated to the target handler
* Provide reasonable default `RSocketStrategies` for the
`AbstractRSocketConnector` and `RSocketInboundGateway`
* Add initial `RSocketInboundGatewayIntegrationTests`
* * Don't use `BytyBuffer` in the `RSocketConnectedEvent.toString()`
* Always `payload.retain()` when we convert `Payload` to `DataBuffer`
* Fix `IntegrationRSocketAcceptor.detectEndpoints()` stream logic
to really iterate over all the `IntegrationRSocketEndpoint` beans
* Fix test to use an explicit `ClientConfig` class for the
`@SpringJUnitConfig`: looks like JUnit 5 is OK to scan for `package
protected` classes as well
* Add request/reply tests into the `RSocketInboundGatewayIntegrationTests`
for both server and client sides
* * Remove `DataBuffer` from `RSocketConnectedEvent.toString()`
* * Fix Checkstyle violation in the RSocketInboundGatewayIntegrationTests
* Use properly `cache()` for the `Mono` in the `ClientRSocketConnector`
* Don't require a `publisherElementTypeExpression` in the
`RSocketOutboundGateway`: the target element type is determined
automatically in the `DefaultRequestSpec.toResponseSpec()`
* SF has deprecated `MediaType.APPLICATION_JSON_UTF8`: fix all its usage
in favor of recommendations to use the `MediaType.APPLICATION_JSON` instead
* Also fix plain `application/json;charset=UTF-8` literals to use
`MediaType.APPLICATION_JSON` instead
* Introduce a `ClientRSocketConnector` to represent a common logic for
client side connection and management an obtained `RSocket`
* Rework the `RSocketOutboundGateway` to perform similar RSocket request
logic on the server side as well.
* Refactor `RSocketOutboundGatewayIntegrationTests` to demonstrate that
RSocket requests work the same way from the server side as well.
For this reason a `CommonConfig` has been extracted with the same
`RSocketOutboundGateway` configuration reuse on both server and client
sides.
* Add initial support for RSockets
* Add `spring-integration-rsocket` module and respective dependencies
* Implement `RSocketOutboundGateway` based on the Spring Messaging
`RSocketRequester`.
This component supports dynamic RSocket properties via expressions
against request message.
to handle `Publisher` for requests, it must be present in the request
message `payload` instead of `FluxMessageChannel` upstream, since the
last one just flattens events to be handled in the `MessageHandler` one
by one.
The result `Mono` is subscribed downstream in the `FluxMessageChannel`
or directly by the `AbstractReplyProducingMessageHandler`.
If result is a `Flux` it is just wrapped into the `Mono` to be processed
downstream by end-user code.
The point is that these request/replies are volatile and live in the
particular context meanwhile a `FluxMessageChannel` is long living
publisher in the application context boundaries.
* The `RSocketOutboundGatewayIntegrationTests` is an adapted copy of
`RSocketClientToServerIntegrationTests` from Spring Messaging
* Add `doOnError()` into the `Flux` created in the
`AbstractMessageProducingHandler` for `Publisher` replies
* * Use singular for the `RSocket` term
* Use no-op `Consumer` for the `strategiesConfigurer` and
`factoryConfigurer` in the `RSocketOutboundGateway` and also
`Assert.notNull()` in the appropriate setters to avoid null check during
`RSocketRequester.builder()` initialization
* Use `TcpServer.create().port(0)` in the
`RSocketOutboundGatewayIntegrationTests` to allow to select free OS port
and bind into it.
The selected port is used later for client configuration in the
`RSocketOutboundGateway` bean definition
* * Change `RSocketOutboundGatewayIntegrationTests.PORT` to lower case
