* Support Java 14
* Provide changes to avoid deprecated Java API
and have a compatibility back to Java 8
* Change affected test classes to JUnit 5 whenever it is possible
* Ignore/Disable some TCP/IP tests which don't pass on Java 14
* Fix (some) TCP tests on JRE 14
* Fix SSL Handshake test - client side handshake is successful with java 14
- change the badClient cert to a badServer cert to force an error on the client side
Co-authored-by: artembilan <raven666>
Co-authored-by: Gary Russell <grussell@pivotal.io>
* 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
* 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
* 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
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
* 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
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
