* Use `tryEmitNext` on Reactor `Sink` since `emitNext` is deprecated
* Add `MessageDeliveryException` emission when `send()` returns `false`
in the `FluxMessageChannel` for `subscribeTo` provided `Publisher`
* Remove redundant `@SuppressWarnings("deprecation")`
* Add `Duration.ofSeconds(10)` to `StepVerifier.verify()`
to avoid infinite wait and lose failing text context on the hang CI build
* Restore `Mono<RSocketRequester> getRSocketRequester()` on
`ClientRSocketConnector` and deprecate it in favor of newly introduced
`RSocketRequester getRequester()`: there is no need in wrapping a
`RSocketRequester` to deferred `Mono` since internal logic of the
`RSocketRequester` on client side is based on lazy-load API of the
`RSocketClient`
Since `RSocketRequester` is now lazy load on client side
there is no need to wrap it into a `Mono`.
* Change `getRSocketRequester()` to a plain getter
If there is a requirement to force connect to the server for receiving
requests from there, the `ClientRSocketConnector.connect()` should be used
* Fix HTTP & WebFlux for a new CORS logic when `*` pattern
is used together with `allowCredentials`
* Fix RSocket module for deprecated API in SF
* The deprecated RMI API is left for the upcoming changes
* GH-3207: RSocket inbound: decode each flux item
Fixes https://github.com/spring-projects/spring-integration/issues/3207
Previously an incoming RSocket Publisher has been decoded as a single unit
leading to extra work on the client side, e.g. a delimiter has to be provided
to treat each payload item as independent
* To have a consistency with Spring Messaging and its `PayloadMethodArgumentResolver`
change an `RSocketInboundGateway` to process inbound payloads as `Flux` and decode
each item independently.
* Change `RSocketDslTests` to remove delimiters and make it consistent with the regular
`RSocketRequester` client
* * Add `decodeFluxAsUnit` option into `RSocketInboundGateway`
* Document the change
* 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
* 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
For the `connect` frame Spring Messaging RSocket support has introduced
an new `@ConnectMapping` annotation.
* Use `@ConnectMapping` in the test controller's method to properly
map to the connection from the client
Looks like there is some connection race condition in Netty on Linux,
so we may not be started on server side fully when we try to select a
port from the OS
* Move local port resolution and, therefore, RSocket server start into
the earlier phase before creating a client
The `http://example.org` is not white-listed in `nohttp` and it
doesn't resolve SSL handshake on HTTPS schema
* Add `@Deprecated` into `SimpleMessageListenerContainerSpec.txSize()`
* It looks like we don't need to manage Reactor dependencies in the
RSocket module: the `io.rsocket:rsocket-transport-netty` brings
everything we need, although it doesn't that with its own supported
versions
* Use non-HTTPS url for `example.org` in test config to avoid SSL
handshake
* 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
* 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
