The `InboundChannelAdapterAnnotationPostProcessor` doesn't use a bean method name
when it parses a `Supplier` bean and only uses a configuration class name + `get`
for method part
* Fix `InboundChannelAdapterAnnotationPostProcessor` to also include a bean method
name into the final bean name for the `MethodInvokingMessageSource` based on
the `Supplier` bean
* Modify `ReactiveInboundChannelAdapterTests` to add one more `Supplier` with the
`@InboundChannelAdapter` to ensure that configuration is still valid after the fix
**Cherry-pick to 5.2.x & 5.1.x**
See SO for more info:
https://stackoverflow.com/questions/64456946/handle-exceptions-errors-other-than-messagingexception-ie-other-error-excepti
In the versions before `5.2.x` the `Error` was wrapped to the `MessagingException`
in the `AbstractRequestHandlerAdvice` and this one was handled properly
on the gateway level with its `errorChannel` configured
* Fix `MessagingGatewaySupport` to catch all the `Throwable` and try to send them as `ErrorMessage`
to the `errorChannel`.
Otherwise unwrap returned `MessagingException` and re-throw an `Error` as is to keep
the current behavior for non-handled exceptions
* Do not wrap `Error` into a `MessagingException` and re-throw as is if there is no `errorChannel`
**Cherry-pick to 5.3.x & 5.2.x**
If there is a `MeterRegistry` bean (any) in the application context,
we add a `MicrometerMetricsCaptor` bean which populates meters further
from the components.
In some case we may load a `MicrometerMetricsCaptor` bean too early
so, not all the stuff around `MeterRegistry` maybe ready.
See Spring Boot and its `MetricsAutoConfiguration`
* Fix the `MicrometerMetricsCaptorRegistrar` the way to rely on the
`ObjectProvider<MeterRegistry>` instead
* Add package protected ctor to the `MicrometerMetricsCaptor` to
provide a target `MeterRegistry` on demand
All of that will ensure that we use an already post-processed `MeterRegistry`
including Spring Boot auto-configuration
**Cherry-pick to 5.3.x & 5.2.x**
Resolves https://github.com/spring-projects/spring-integration/issues/3395
Outbound remote file gateway parser requires `expression` even though some
commands don't need or use it.
* Propagate the empty string for `expression` attribute
* Fix default (`payload`) expression logic in the `AbstractRemoteFileOutboundGateway`
**Cherry-pick to `5.3.x`**
The `Mono.doOnSuccess()` is always called for completed `MonoSink`
even if the value is `null`
* Fix `IntegrationReactiveUtils.messageSourceToFlux()` to check a
message for `null` before calling `AckUtils.autoAck()`
* Add an `logger.error()` message when `doOnError()` is invoked for that `Mono`
**Cherry-pick to 5.3.x**
* GH-3376: Remove gauges on application ctx close
Fixes https://github.com/spring-projects/spring-integration/issues/3376
The `MeterRegistry` may request meters on application shutdown.
The gauges for channels, handlers and message sources don't make sense
at the moment since all those beans are going to be destroyed.
* Remove gauges for channel, handler and message source numbers from the
`IntegrationManagementConfigurer.destroy()`
**Cherry-pick to 5.3.x & 5.2.x**
* * Add `MicrometerImportSelector` to conditionally load
a `MicrometerMetricsCaptorConfiguration` when `MeterRegistry`
is on class path.
* Make `MicrometerMetricsCaptorConfiguration.integrationMicrometerMetricsCaptor()`
bean dependant on the `ObjectProvider<MeterRegistry>`
* Make `IntegrationManagementConfiguration.managementConfigurer()`
dependant on the `ObjectProvider<MetricsCaptor>`.
This way the `IntegrationManagementConfigurer` is destroyed before
`MeterRegistry` when application context is closed
* Deprecate `MicrometerMetricsCaptor.loadCaptor()` in favor of
`@Import(MicrometerImportSelector.class)`
* * Add `MicrometerMetricsCaptorRegistrar` to register a `MICROMETER_CAPTOR_NAME`
bean when `MeterRegistry` is on class path and no `MICROMETER_CAPTOR_NAME` bean yet.
* Make `IntegrationManagementConfiguration.managementConfigurer()`
dependant on the `ObjectProvider<MetricsCaptor>`.
This way the `IntegrationManagementConfigurer` is destroyed before
`MeterRegistry` when application context is closed
* Deprecate `MicrometerMetricsCaptor.loadCaptor()` in favor of
`@Import(MicrometerMetricsCaptorRegistrar.class)`
* Fix test to make a `MeterRegistry` bean as `static` since
`@EnableIntegrationManagement` depends on this bean definition now
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/config/EnableIntegrationManagement.java
# spring-integration-core/src/main/java/org/springframework/integration/config/IntegrationManagementConfiguration.java
# spring-integration-core/src/main/java/org/springframework/integration/config/IntegrationManagementConfigurer.java
* Fix some deprecation warnings
Fixes https://github.com/spring-projects/spring-integration/issues/3373
The `AbstractInboundFileSynchronizer` doesn't consider that
`hostPort` from `Session` could be in an IPv6 syntax
* Parse the `hostPort` from `Session` in a manner that only the last
`:` is treated as a port delimiter
**Cherry-pick to 5.3.x & 5.2.x**
* GH-3374: Fix scan for BF propagation
Fixes https://github.com/spring-projects/spring-integration/issues/3374
An internal `ClassPathScanningCandidateComponentProvider` instance in the `IntegrationComponentScanRegistrar`
does not propagate a provided `registry`.
* Implement `getRegistry()` on the internal `ClassPathScanningCandidateComponentProvider` to propagate
a provided into the `registerBeanDefinitions()` a `BeanDefinitionRegistry`
* Add `@Conditional` on some scanned `@MessagingGateway` in the `EnableIntegrationTests`
**Cherry-pick to 5.3.x & 5.2.x**
* * Remove unused import
* Restore `unused` warning on the unused registry arg
* GH-3370: Remove synchronized from RemoteFileUtils
Fixes https://github.com/spring-projects/spring-integration/issues/3370
The `synchronized` on the `RemoteFileUtils.makeDirectories()` makes an application too
slow, especially when we deal with different paths in different sessions
* Remove the `synchronized` from that method and rework `SftpSession.mkdir()`
to return `false` when "A file cannot be created if it already exists" exception
is thrown from the server.
Essentially make an `exists()` call to be sure that an exception is really related
to "file-already-exists" answer from the server
**Cherry-pick to 5.3.x, 5.2.x & 4.3.x**
* * Re-throw an exception in the `SftpSession.mkdir()`
when error code is not `4` or remote dir does not exist
* * Check `session.mkdir()` result in the
`RemoteFileUtils` to throw an `IOException` when `false`
* * Fix mock test to return `true` for `mkdir` instead of `null`
* The `into()` query can't infer the type for entity if we provide `Object.class`
* The `updateFirst()` does not support sort queries any more - replace with `findAndModify()`
* Add `getMessageGroupCount()` into tests
**Cherry-pick to 5.3.x & 5.2.x**
* Add gauges for queue channel size
The `QueueChannel` provides a current size and remaining capacity metrics
* Add Micrometer gauges into `QueueChannel` to expose the current values
of the size and remaining capacity
**Cherry-pick to 5.3.x, 5.2.x & 5.1.x**
* * Revert `@SuppressWarnings("unchecked")` for test
* Document new gauges for queue channel
* * Fix IntegrationManagementConfigurer for NPE on `metricsCaptor`
* Fix wording in meter descriptions
Co-authored-by: Michel Jung <michel.jung89@gmail.com>
Co-authored-by: Michel Jung <michel.jung89@gmail.com>
* GH-3344: Treat kotlin.Unit return as null in MMIH
Fixes https://github.com/spring-projects/spring-integration/issues/3344
When function lambda doesn't return anything (e.g. a `void` method call is the last one),
Kotlin produces a `kotlin.Unit` instance as a return value which is not null and produced
as a reply message payload.
* Fix `MessagingMethodInvokerHelper` to treat a `kotlin.Unit` as `null` for reply
making Kotlin lambdas working the same way as Java lambdas when we don't return anything
from from there
**Cherry-pick to `5.3.x`**
* * Introduce `ClassUtils.isKotlinUnit(Class)` API;
use it in the `MessagingMethodInvokerHelper` instead of
`.getName().equals()`
* * Fix since on new `isKotlinUnit()` API
Related to https://stackoverflow.com/questions/62761903/spring-integration-reactive-streams-support-exception-in-creating-a-reactive
The `MessagingGatewaySupport` creates an internal endpoint
for consuming messages from the provided `replyChannel`.
The endpoint type depends on the channel type.
The `ReactiveStreamsConsumer` was missing a `BeanFactory` injection
causing an error when `ReactiveStreamsConsumer` tries to extract a default `ErrorHandler`
from `BeanFactory`
* Refactor `MessagingGatewaySupport` to inject a `BeanFactory` to all
the possible correlator endpoints.
Also always call `afterPropertiesSet()` for all of them
**Cherry-pick to 5.3.x & 5.2.x**
Close the pool so that any sessions returned after the factory is
`destroy()`ed are closed.
* Call `removeAllIdleItems()` in `close()`.
* Close sessions in `SftpStreamingMessageSourceTests`.
**cherry-pick to all supported branches**
* Fix MessagingGatewaySupport for reactive error
The `onErrorResume()` was in a wrong place for the
`doSendAndReceiveMessageReactive()`: we have to catch all the exceptions
from the top level `Mono`, not only a reply one as it was before.
Ensure in HTTP and WebFlux test that behavior is fixed
**Cherry-pick to `5.3.x` & `5.2.x`**
* * Remove unused imports
Co-authored-by: Artem Bilan <abilan@vmware.com>
Resolves https://github.com/spring-projects/spring-integration/issues/3315
`maxFetchSize` ignored with filters supporting single file filtering (default).
This breaks "fair" rotation with the `RotatingServerAdvice`.
Honor `maxFetchSize`, even with filters that support single file filtering.
**cherry-pick to 5.3.x, 5.2.x**
Fixes https://github.com/spring-projects/spring-integration/issues/3307
The `DefaultLockRepository.acquire()` is transactional method and
can fail with the `TransactionTimedOutException`.
When we call `JdbcLock.lock()`, we expect an attempt until we really obtain a lock.
* Treat a `TransactionTimedOutException` as a `TransientDataAccessException` and
therefore retry a locking attempt logic
**Cherry-pick to 5.3.x, 5.2.x & 4.3.x**
(cherry picked from commit b0cd0156c7)
Resolves https://github.com/spring-projects/spring-integration/issues/3299
Connect before creating the `TcpNioConnection` object and publishing the
`TcpConnectionOpenEvent`.
This was a regression caused by supporting connect timout; which moved
the connect to after the object was created and event published, causing
the `connectionId` to start with `unknown`.
**cherry-pick to 5.3.x, 5.2.x**
Fixes https://github.com/spring-projects/spring-integration/issues/3288
* For better end-user experience with Kotlin DSL and get a gain from
existing `Transformer` implementations add a `transform(Transformer)`
EI-method into the `KotlinIntegrationFlowDefinition`
* Also add `filter(MessageSelector)` for any out-of-the-box `MessageSelector`
**Cherry-pick to 5.3.x**
* GH-3282: Fix JdbcMetadataStore for DuplicateKeyEx
Fixes: https://github.com/spring-projects/spring-integration/issues/3282
The `INSERT INTO ... SELECT ... FROM ... HAVING` may fail with
`DuplicateKeyException` in between transactions.
* Catch `DuplicateKeyException` from in the `tryToPutIfAbsent()`
and return `0` as a fact of not inserted to let other logic to work
as expected.
There is no test coverage for this since it is almost impossible to
reproduce such a race condition on DB
**Cherry-pick to 5.3.x & 5.2.x**
* * Remove misleading message in the comment sentence
Fixes https://github.com/spring-projects/spring-integration/issues/3276
The `onErrorResume` for the `MessagingGatewaySupport.doSendAndReceiveMessageReactive()`
was in wrong place: only for the `buildReplyMono` which works only
when an outbound flow is fully based on reactive channels.
With a regular direct channel we can get an exception from the
`sendMessageForReactiveFlow` which is not covered with the mentioned
`onErrorResume` for the error handling on the configured `errorChannel`
Cherry-pick to `5.2.x & 5.1.x`
1. Add proper terminating tags for `request-handler-advice-chain`.
2. Replace `int:request-handler-advice-chain` with `int-http:request-handler-advice-chain` when used inside of an `int-http:outbound-gateway`.
3. Replace `<bean ref="*" />` with `<ref bean="*" />`
4. Replace `</int:int:service-activator>` with `</int:service-activator>`
Fixes https://github.com/spring-projects/spring-integration/issues/3271
When exception happens at `.withPayload(session.readRaw(remotePath))`
in the `AbstractRemoteFileStreamingMessageSource` we don't close session.
The resource leaking happens in the caching session factory
* Add `session.close();` into the `catch (IOException e) {`
in the `AbstractRemoteFileStreamingMessageSource.doReceive()`
to clean up resources properly
**Cherry-pick to 5.2.x, 5.1.x & 4.3.x**
It turns out that relative path in the property
`<property name="file" value="src/checkstyle/checkstyle-suppressions.xml"/>`
in some cases is resolved against a Gradle deamon dir as a root for configs
* Fix Checkstyle plugin config to use an absolute path in the project for
the `configDirectory`.
* Since `configDirectory` is exposed as a Checkstyle config variable,
we can use its `${config_loc}` placeholder to rely on the absolute path
in the project
Don't allow a `waitForConfirmsTimeout` if the factory is not configured
for simple publisher confirmations.
Otherwise, a runtime error will occur.
**cherry-pick to 5.2.x, 5.1.x**
