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
