* Encoding in AbstractHttpRequestExecutingMessageHandler.java is now done when flag is set
* Added test for URI Encoding
* Fixed checkstyle violations
**Cherry-pick to 5.1.x**
* 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
While investigating an SI build failure, I noticed that there is
a timeout available for when connecting channels.
This won't resolve the build issue (where the session closed) but
worth adding as a property.
The `AmqpInboundGateway` and `JmsInboundGateway` don't delegate to `super`
in their `doStart()/doStop()` implementations causing the problem with
an internal `replyMessageCorrelator` missed the proper lifecycle
management
**Cherry-pick to 5.1.x & 5.0.x**
Since SF has deprecated `StandardAnnotationMetadata` ctors in favor
of factory method, we can't extend it any more to adapt annotation
attributed by the map generated from the XML attributes
* Introduce an `AnnotationMetadataAdapter` to request a
`getAnnotationAttributes()` implementation which is only a method used
in the target `registerBeanDefinitions()` implementations
* Use a new `AnnotationMetadataAdapter` whenever the `StandardAnnotationMetadata`
has been used before
* 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
* Move SF dependencies to the latest BUILD-SNAPSHOT
To avoid class loader issues it is better to align Spring Data
dependencies with SF version we use explicitly.
This way we don't have a `ClassLoader` issue when a newly introduced
`TransactionManager` might not be visible from the previous versions
* Fix code style warnings in the `TransactionSynchronizationFactoryBean`
* Use `JavaUtils` in the `TransactionSynchronizationFactoryBean` to
decrease code complexity
* * Fix CQ Gemfire tests for upgrades compatibility
* For better performance and consistency use a `MergedAnnotations` in
the `MethodAnnotationPublisherMetadataSource` instead of
`AnnotatedElementUtils`
* Remove deprecated API from the `PublisherMetadataSource` hierarchy
* use equals
* inner assignment
* local before return
* unnecessary locals
* catch and throw
* uninstantiable with no statics
* implement `Serializable` in `Comparator` to enable `TreeMap` serialization
* exceptions as flow control
* 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.
Fixes https://github.com/spring-projects/spring-integration/issues/2908
* make sure the attribute is taken into account in @Header annotation
* remove useless spaces according to checkstyle rules
* make sure the expression attribute is taken into account as well in @Payload annotation
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 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
* 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
* Add support for Kotlin JSR223 scripts
* Add required Kotlin dependencies into the `spring-integration-scripting`
module
* Introduce `KotlinScriptExecutor` to interact with the
`KotlinJsr223JvmLocalScriptEngineFactory` directly since there is no
`META-INF/services/javax.script.ScriptEngineFactory` file in the Kotlin
* Also set an `idea.use.native.fs.for.win` system property to `false` in
this class to disable check for native support on Windows.
(Might be removed in future Kotlin versions)
* Move `ScriptParser.getLanguageFromFileExtension()` logic into the
`ScriptExecutorFactory.deriveLanguageFromFileExtension()` since the same
one must be applied in the `DslScriptExecutingMessageProcessor`, too.
* Modify tests to reflect Kotlin support
* Fix some test scripts to their official extensions
* * Add JavaDocs
* Polishing according Sonar objections
