* GH-3089: Add AmqpInGateway.replyHeadersMappedLast
Fixes https://github.com/spring-projects/spring-integration/issues/3089
In some use-case we would like to control when headers from SI message
should be populated into an AMQP message.
One of the use-case is like a `SimpleMessageConverter` and its `plain/text`
for the String reply, meanwhile we know that this content is an
`application/json`.
So, with a new `replyHeadersMappedLast` we can override the mentioned
`content-type` header, populated by the `MessageConverter` with an
actual value from the message headers populated in the flow upstream
* Introduce an `AmqpInboundGateway.replyHeadersMappedLast`; expose it
on the DSL and XML level
* Use newly introduced `MappingUtils.mapReplyMessage()`
* Optimize `DefaultAmqpHeaderMapper` to not parse JSON headers at all
when `JsonHeaders.TYPE_ID` is already present (e.g. `MessageConverter`
result)
* Also skip `JsonHeaders` when we `populateUserDefinedHeader()`
**Cherry-pick to 5.1.x**
* * Fix language and package typos
* Add missed `@param` in JavaDoc of the `AmqpBaseInboundGatewaySpec.batchingStrategy()`
* Extract a `RabbitTemplate` `MessageConverter` to use for reply messages
conversion - pursue a backward compatibility
* GH-3090: Add `logout() to `FtpSession.close()`
Fixes https://github.com/spring-projects/spring-integration/issues/3090
Without `logout()` the FTP session is not closed at all,
but just the connection is closed.
Some FTP servers close those sessions eventually anyway, but some just
leak with resources.
**Cherry-pick to 5.1.x & 4.3.x**
* * Migrate `SessionFactoryTests` to JUnit 5
Fixes https://github.com/spring-projects/spring-integration/issues/3026
**Cherry-pick to `5.1.x`**
* Populate proper `FileTransferringMessageHandler` impl from DSL spec
implementations.
This way we are able to use a provided `chmod` from Java DSL
* Added `FileTransferringMessageHandlerSpec` ctor TODO
* Update SftpTests
* Code cleanup; `@Ignore` `SftpTests.testSftpOutboundFlowWithChmod()`
since it doesn't work properly on Windows
* Extract `BaseIntegrationFlowDefinition`
Kotlin inline reified functions cannot override as syntax sugar generic
Java methods.
* Extract a `BaseIntegrationFlowDefinition` with strong typed methods,
plus those which doesn't have a syntax sugar variants
* Leave in the `IntegrationFlowDefinition` only those generic methods
which are just a syntax sugar without any types requirements
This way we can write Kotlin inline reified functions as an extension
with the same names to make a Kotlin DSL much cleaner
* * Override methods in the IntegrationFlowDefinition for bytecode compatibility
* Extract `protected` getters and setters for `BaseIntegrationFlowDefinition`
properties to allow a proper extension
* Use those getters and setters in the code
* * Add // NOSONAR for overridden methods
Related to https://github.com/spring-cloud/spring-cloud-stream/pull/1824
There are some use-cases when we would like to further customize a
`RabbitTemplate` encapsulated in the `AmqpOutboundEndpoint`.
For this purpose there is just enough to make its getter as `public`.
Also make a `AmqpHeaderMapper` available same way via `public` getter
* Ensure that dynamic routes are included into graph
Modify an `IntegrationGraphServerTests` to be sure that dynamic routes
are included into the graph (with links) after sending a message to the
router and rebuilding a graph
* * Fix test for the actual numbers to expect
Fixesspring-projects/spring-integration#3076
* Return `null` instead of throwing an exception
* Fix license header
* Add missing `@since`
* Avoid over-engineered test logic
* Fix code style
* Test non-existent file does not get created
* Fix: remove unused import
* GH-3079: Use getMostSpecificMethod for SpEL calls
Fixes https://github.com/spring-projects/spring-integration/issues/3079
It turns out that we need to use a *most specific* method for the target
to be called reflectively from the SpEL
NOTE: We drop a *Method not found* error in case of wrong method source
since now we find a right source via `ClassUtils.getMostSpecificMethod()`
**Cherry-pick to 5.1.x**
* * `@Ignore` `MethodInvokingMessageProcessorTests.testProcessMessageMethodNotFound()`
instead of removal
* Refinement for gateway Mono processing
* Introduce a `MessagingGatewaySupport.MonoReplyChannel` instead of
`FutureReplyChannel` for better on demand handling and reusing a
`Mono` returned from the target handler
* Refactor `GatewayProxyFactoryBean` to identify a target return type
(including generics for `Function`) during initialization
* Handle a `Mono` return type via
`MessagingGatewaySupport.sendAndReceiveMessageReactive()`
* Some `@Nullable` in the `GatewayProxyFactoryBean` and `ExpressionUtils`
* Add `MonoFunction` test-case into the `FunctionsTests.kt`
* * Deprecate `GatewayProxyFactoryBean.setServiceInterface()` in favor of
ctor initialization
* Fix `GatewayProxyFactoryBean.setServiceInterface()` usage in tests
The method reference together with a `IntegrationFlows.frm(Supplier<?>)`
do the trick to avoid a method name resolution and also gives us a code
navigation in the IDE
Fixes https://github.com/spring-projects/spring-integration/issues/3061
Without a `@DirtiesContext` we keep not only a ctx in the cache, but
also an embedded DB instance, which is shared between contexts.
When ctx cache clean up happens, several ctxes would like to destroy
their associated embedded DB which, essentially, is the same in-memory
instance
* The `@DirtiesContext` give us a chance to destroy embedded DB for
the particular ctx in isolation
* Improve `channel.adoc`: polishing, new channels, java config
* Make `LoadBalancingStrategy` in the `DirectChannel` ctor as
`@Nullable` to reflect the real logic behind
* More Dos and polishing according PR comments
* Mention WebFlux and RSocket endpoints in the `endpoint-summary.adoc`
table
* More reactive streams docs
* `SourcePollingChannelAdapter` polishing
* Wrap multi-value publisher into `Mono.just()` in the `AbstractMessageProducingHandler`
instead of emitting just only a first item for the standard reply
Doc polishing
* Hide `toReactivePublisher()` from lambdas
When an `IntegrationFlow` is declared via lambda, it is impossible
to materialize it as a `Publisher` since we lose a Lambda context and
finish with a `NoSuchBeanException` when we would like to inject that
`Publisher`
* Make `IntegrationFlowDefinition.toReactivePublisher()` as `protected`
and expose it on the `IntegrationFlowBuilder` level
* Use `Channels` as a singleton: no reason in overhead for its instances
* Some code style polishing for `IntegrationFlowDefinition`
* Restore `Channels.super()` call
* 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
Fixes https://github.com/spring-projects/spring-integration/issues/3052
Starting with version `5.1`, a `LambdaMessageProcessor` is based on the
`MessageConverter` instead of plain `ConversionService`.
(A `ConfigurableCompositeMessageConverter` is used from the application
context.)
However a type conversion based on the `@IntegrationConverter` is lost
in the `GenericMessageConverter` because it doesn't use an
`integrationConversionService` from the application context
* Change `ConfigurableCompositeMessageConverter` to configure a
`GenericMessageConverter` with an `integrationConversionService`
if any
* Fix `MessagingMethodInvokerHelper` to populate a `BeanFactory` into
its internal `ConfigurableCompositeMessageConverter`
* Ensure in the `LambdaMessageProcessorTests` that
`@IntegrationConverter` is applied for ``LambdaMessageProcessor` as well
**Cherry-pick to 5.1.x**