Fixes: https://github.com/spring-projects/spring-integration/issues/2820
The current `FtpRemoteFileTemplate.exists()` implementation obtains a
`Session` for the `NLST_AND_DIRS` mode, but doesn't close it.
* Fix the `FtpRemoteFileTemplate.exists()` method to delegate to `super`
for the proper interaction with a `Session`
**Cherry-pick to 5.1.x, 5.0.x & 4.3.x**
* Support generics in the `JsonToObjectTransformer`
* Deprecate `JsonObjectMapperAdapter` if favor of `default` methods in
the `JsonObjectMapper`
* Introduce `JsonObjectMapper.fromJson(Object, ResolvableType)` to
support generics during deserialization
* Add `JsonHeaders.RESOLVABLE_TYPE` header handling for the
`ResolvableType` management
* Add `ResolvableType` argument into the `JsonToObjectTransformer`
* Change the `JsonToObjectTransformer` logic to consult request message
headers first
* Add `ResolvableType`-based factory method into the `Transformers`
* Document the change
* * Use `0` for conversion to array for headers to remove
in the `JsonToObjectTransformer`
* Fix synchronization smell in the `MessagePublishingInterceptor`
* Cache `Pointcut` in the `PublisherAnnotationAdvisor`;
fix `@SuppressWarnings` also
* Fix complexity in the `IntegrationMBeanExporter`
After `MessagingAnnotationPostProcessor` fix for the late endpoints
registration we end up with the fact that `IntegrationMBeanExporter`
tries to register an `MBean` for the `MessageHandler/MessageSource`
one more time after parsing an `AbstractEndpoint`.
We don't fail because we catch an exception for already registered MBean
and just log it with ERROR
* Fix `IntegrationMBeanExporter` to check for
`MessageHandler/MessageSource` presence in the registered `objectNames`
* Some refactoring in the `IntegrationMBeanExporter` and fixes for
Sonar smells
* INT-2277: Register ChResolver & ErrHandler beans
JIRA: https://jira.spring.io/browse/INT-2277
To avoid extra objects at runtime and reuse a central configuration,
register `BeanFactoryChannelResolver` and `MessagePublishingErrorHandler`
bean via `DefaultConfiguringBeanFactoryPostProcessor`
* Use those beans whenever it is necessary via `IntegrationContextUtils`
factory methods against provided `BeanFactory`
* To avoid changes in the non-managed test, those new factories fall
back to a new instance if there is no an appropriate bean in the `beanFactory`
* * Add `Assert.notNull(beanFactory)` to new factory methods
* GH-2690: Add MessageHandlerMethodFactory beans
Fixes https://github.com/spring-projects/spring-integration/issues/2690
For more end-user flexibility and for simplicity of the `MessagingMethodInvokerHelper`
logic, add `IntegrationContextUtils.MESSAGE_HANDLER_FACTORY_BEAN_NAME` and
`IntegrationContextUtils.LIST_MESSAGE_HANDLER_FACTORY_BEAN_NAME`
infrastructure beans
* Use mentioned beans in the `MessagingMethodInvokerHelper` if any,
otherwise fallback to the locally configured `MessageHandlerMethodFactory`,
although this is necessary only for our non-Spring-based unit tests
* Relax `BeanFactory` requirement for the `EvaluationContext` since it
is going to be there in the Spring-based environment, but might not be
available in the plain unit tests
* Provide some optimization and refactoring for the `MessagingMethodInvokerHelper`
* Remove deprecated `HandlerMethodArgumentResolversHolder` and
`ARGUMENT_RESOLVERS_BEAN_NAME` & `LIST_ARGUMENT_RESOLVERS_BEAN_NAME`
bean definitions and constants for their names
* * Revert `getEvaluationContext(false)` usage.
* Fix `MessagingMethodInvokerHelper` to propagate `BeanFactory` to
argument resolvers if any
Fixes https://github.com/spring-projects/spring-integration/issues/2799
**Cherry-pick to 5.1.x & 5.0.x**
When `AnnotationGatewayProxyFactoryBean` is used for the one-way (`void`)
POJI method invocation and downstream processing is based on an
`ExecutorChannel`, the default `errorChannel` value from the annotation
is resolved to the empty string with is set to the target gateway proxy
and can not be resolved to the target bean eventually in the
`MessagePublishingErrorHandler` in case of exception
* Check `errorChannel` attribute for empty string and don't set it into
the `errorChannelName`.
This way the `MessagePublishingErrorHandler` will resolve to the global
`errorChannel` as expected.
* Fix new Sonar smells for MMIH
* Fix complexity smells in the `MessagingMethodInvokerHelper`
* Reuse `get()` in the `ZookeeperMetadataStore` in case of `putIfAbsent()` error
* Polishing for `ZookeeperMetadataStoreTests`
* Fix for `hasUnqualifiedMapParameter`
* Fix `findHandlerMethodsForTarget()` complexity
* * Fix typo and remove FQCN for `ClassUtils`
Prior to this commit, `RedisAvailableRule.apply()` threw an
`AssumptionViolatedException` when Redis was unavailable. That caused
the execution of the current test class and all pending test methods to
be stopped immediately. Instead, it now returns a `Statement` that
throws the exception in case Redis is unavailable which will only skip
the current test.
Resolves#2782.
Fixes https://github.com/spring-projects/spring-integration/issues/2753
* Remove Guava dependency and its minor functionality from the
`StoredProcExecutor`
* Remove `@ManagedResource` and its operations/attributes from
`StoredProcExecutor` since they are not relevant any more
* Remove tests related to JMX and Guava
* Refactor all other tests in the affected classes
* Some code polishing in the `StoredProcExecutor`
* Fix MMIHelper for reinitialization
If we provide a custom `MessageHandlerMethodFactory`, the
`MessagingMethodInvokerHelper` obtains its bean and reinitialize a
`handlerMethod`, but it is done only for single, explicit
and provided method.
In case of `Function` or `Consumer` we use local names for methods to
extract, but this is not populated to properties of the
`MessagingMethodInvokerHelper`
* Change an internal `MessagingMethodInvokerHelper` logic to recreate
`InvocableHandlerMethod` instances based on the `MessageHandlerMethodFactory`
bean for all the methods scanned on the target.
* Populate a `handlerMethodsList` for the purpose above even if we have
only one candidate
* Fix `AggregatorParserTests` to reflect the current logic around
`handlerMethodsList`
* Prove that new logic works well with a custom `MessageHandlerMethodFactory`
bean in the `MessagingAnnotationsWithBeanAnnotationTests`
**Cherry-pick to 5.1.x**
* * Move CTOR to the proper place
* INT-3459: Log exceptions in case of failOver
JIRA: https://jira.spring.io/browse/INT-3459
When `UnicastingDispatcher` is configured with `failOver` (true by default),
it loses exceptions it caught with previous handler when the next one
processes message properly
* Add INFO logging for exceptions which are caught before going to fail
over to the next handler
* * Address PR comments
* * More PR comments
* Add a note about this logging into the `channel.adoc`
* Add `RateLimiterRequestHandlerAdvice.getRateLimiter()` to get access
to the configured `RateLimiter` for possible low-level operations and
management
* Fix the `RateLimiterRequestHandlerAdviceTests` to calculate the sleep
based on the `reservePermission()` plus `REFRESH_PERIOD`
Resolves https://github.com/spring-projects/spring-integration/issues/2777
If the filter supports it, defer filtering until the last possible moment.
Then, the worst case scenario after a catastrophic failure (e.g. power loss),
would be that at most one file will be incorrectly filtered on restart.
Polishing and add more tests.
Polishing Javadocs
More Polishing
Final polishing
More polishing.
Polishing and docPolishing and docs.
* Fix typos in Docs
* Defer Messaging annotations process
The `AbstractMethodAnnotationPostProcessor` and its implementations
have a `beanFactory.getBean()` call for the `@Bean` methods with
Messaging annotations.
This is done, actually, from the
`MessagingAnnotationPostProcessor.postProcessAfterInitialization()`
which might be still too early in some scenarios, like Spring Cloud Feign
with its child application contexts being initialized from the
`FeignClientFactoryBean`, causing a `BeanCurrentlyInCreationException`
See https://stackoverflow.com/questions/54887963/beancurrentlyincreationexception-when-using-spring-integration-with-spring-cloud
* Implement a `SmartInitializingSingleton` for the `MessagingAnnotationPostProcessor`
and gather `Runnable` wrappers for newly introduced `postProcessMethodAndRegisterEndpointIfAny()`
to be called later in the `afterSingletonsInstantiated()` when context is
still in the initialization phase.
All runtime-registered beans are going to be processed normally from the
regular `postProcessAfterInitialization()`
**Cherry-pick to 5.1.x**
* * Fix unused imports in the `MessagingAnnotationsWithBeanAnnotationTests`
* * Fix `IntegrationEndpointsInitializer` in the testing framework to handle
all the possible `AbstractEndpoint` beans registration.
See its JavaDocs for more info
* Fix `AbstractCorrelatingMessageHandlerParser` and
`AbstractConsumerEndpointParser` to use bean names for `outputChannel`
and `discardChannel` instead of bean references.
Since `MessagingAnnotationPostProcessor` now registers endpoints and
beans for channels much later, than parsers, we can't rely on bean
references any more there.
* Fixes for failing tests which expected `outputChannel/discardChannel`
bean references, when it is already just their names for late binding.
* Apply some code style polishing for the affected classes.
* Add `@Nullable` for `MessageSelector` parameter in the `QueueChannel.purge()`
Fixes https://github.com/spring-projects/spring-integration/issues/2770
Only create an evaluation context for header expressions if we actually
have header expressions.
* Some `AbstractMessageSource` refactoring to avoid unnecessary code and
some optimization
**Cherry-pick to 5.1.x**
* Fix new Sonar smells
* Fix some old Sonar smells as well
* Fix Micrometer leaks in the `PollableChannel` when we register
meters, but don't remove them.
* * Fix NPE around `MetricsCaptor` in channels
* * Fix new smells according test report
* * Further Sonar smell fixes
* * More smell fixes for `MessagingMethodInvokerHelper`
* Remove `throws Exception` from `AbstractMessageHandler.destroy()`
* * Fix complexity in the `MessagingMethodInvokerHelper.processInvokeExceptionAndFallbackToExpressionIfAny()`
JIRA: https://jira.spring.io/browse/INT-4573
* Fix check order for headers first in the `resolveObjectName()` and
`resolveOperationName()`.
Then fallback to defaults configured on the `OperationInvokingMessageHandler`
* Remove also a deprecated API in the `OperationInvokingMessageHandler`
* Remove requirements for `object-name` and `operation-name` XML
attributes since those options can be provided in the request message
headers
* Fix `OperationInvokingChannelAdapterParserTests` for proper headers
resolution
* Mention `JmxHeaders.OBJECT_NAME` and `JmxHeaders.OPERATION_NAME`
headers in the `jmx.adoc`
JIRA: https://jira.spring.io/browse/INT-4559
* Return a single item from result only if
`maxRows == null || maxRows == 1`
* Remove deprecated `max-rows-per-poll` from the
`JdbcOutboundGateway.java` and its XSD and parsers
Fixes https://github.com/spring-projects/spring-integration/issues/2760
* The `assertThatExceptionOfType()` is more convenient,
than `assertThatThrownBy`, so, replace all the usages accordingly
* Fix JavaDoc typo in the `AbstractScriptExecutingMessageProcessor`
* Fix Sonar smells for `throws Exception` in `AbstractScriptExecutingMessageProcessor`
hierarchy and some code polishing for them
* GH-2749: Deprecate ChannelInterceptorAware
Fixes https://github.com/spring-projects/spring-integration/issues/2749
The `org.springframework.messaging.support.InterceptableChannel` provides
exact functionality as `ChannelInterceptorAware`
* Make `ChannelInterceptorAware extends InterceptableChannel`
* Suppress deprecation warning whenever we need to keep backward
compatibility
* Fix all other places to deal with `InterceptableChannel` already
* GH-2749: Deprecate ChannelInterceptorAware
Fixes https://github.com/spring-projects/spring-integration/issues/2749
The `org.springframework.messaging.support.InterceptableChannel` provides
exact functionality as `ChannelInterceptorAware`
* Make `ChannelInterceptorAware extends InterceptableChannel`
* Suppress deprecation warning whenever we need to keep backward
compatibility
* Fix all other places to deal with `InterceptableChannel` already
* * Fix `channel.adoc` for the current version
* GH-2759: Fix CorrelationData.future
Fixes https://github.com/spring-projects/spring-integration/issues/2759
The outbound endpoints wrap user correlation data in a wrapper.
If the user data is a `CorrelationData`, we must delegate methods
involving the `Future<?>` and `returnedMessage` to the user data.
**cherry-pick to 5.1 and switch AMQP to snapshots**
* Polishing - remove redundant override.
* Add debug log with null correlation data
* Use `IntegrationUtils.wrapInHandlingExceptionIfNecessary()` whenever
it is possible to avoid double wrapping into the `MessageHandlingException`
* Some code polishing for affected classes `@Nullable`, streams, diamonds etc.
* The Gradle `checkTestConfigs` task deals only with resources,
so narrowing its `outputs` to the `build/resources`
* The Gradle `updateCopyrights` tasks deals only with compiled classes,
so narrowing its `outputs` to the `build/classes`
Mostly thanks to IDEA's plugin: https://plugins.jetbrains.com/plugin/10345-assertions2assertj
There is still a lot of work to do when complex and composite matchers are used.
* Add `awaitility` dependency and deprecate `EventuallyMatcher` in favor
of `awaitility`
* Remove Hamcrest from dependencies and disable JUnit & Hamcrest
static imports to encourage to use only AssertJ
* Migrate JUnit assumptions in rules to AssertJ's assumptions
* Deprecate some custom matchers in favor of existing in Hamcrest
after upgrading the last to version `2.1`
* Replace `ExpectedException` rules with `assertThatThrownBy()`
* Mention `MessagePredicate` in the `testing.adoc`
