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
https://build.spring.io/browse/INT-MASTERSPRING40-681/
* Create an `ImapServer` only in the `@Before` method.
Looks like the `final` property is initialized only once for the whole
test class
* Change `LongRunningIntegrationTest` to the `@ClassRule`
* Fix `testMessageHistory()` and re-enable it
* Remove redundant `this.imapIdleServer.resetServer()` since we now have
a fresh `ImapServer` instance for every test method.
* Fix `AbstractMessageProcessingTransformer` to react for the
`AbstractIntegrationMessageBuilder` invocation result and don't wrap it
into the `Message`
* Demonstrate functionality in the `CacheRequestHandlerAdviceTests`
* Polishing and Docs
* Fix JavaDocs warnings
Doc polishing.
* Optimize DefaultSftpSessionFactory
Related to https://build.spring.io/browse/INT-MASTERSPRING40-677/
Doesn't look like `DefaultSftpSessionFactory.getSession()` needs
locking around `sharedJschSession`
* change the logic in the `getSession()` to store a `sharedJschSession`
into the local variable and if it is `null` or not connected, create a
new `JSchSessionWrapper`, connect it and store to the `sharedJschSession`
back into the `sharedJschSession` property if `this.isSharedSession`.
This way we always deal with `sharedJschSession` anyway if it is valid
or create a new fresh one if that is invalid.
Without locking we always get an actual state of the `sharedJschSession`
and don't fall into the race condition when `sharedJschSession` is invalid,
but we can't connect to the SFTP channel from the `sftpSession.connect()`
* * Wrap `sharedJschSession` initialization to the lock
* * Store `sharedJschSession` back when it is really fresh and while the lock
