* 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`
Fixes https://github.com/spring-projects/spring-integration/issues/2752
The logic in the `IntegrationRequestMappingHandlerMapping` fully depends
on the application context it has been registered with, therefore any
arbitrary `ContextRefreshedEvent` doesn't fit our requirements.
More over it may cause a problem with missed mappings when parent-child
configuration is used.
**Chery-pick to 5.1.x, 5.0.x & 4.3.x**
* Upgrade to Gradle 5.2.1, SonarQube 2.7, asciidoctor 1.5.10,
Apache Sshd 2.2.0, AsertJ 3.12.0, Curator Framework 4.1.0, room Tool 1.12.0,
Checkstyle 8.17
* remove Eclipse Link support in JPA tests since it is not compatible
with Java 11
* Move 5.1 changes to the `changes-5.0-5.1.adoc`; start new "What's New"
Fixes https://github.com/spring-projects/spring-integration/issues/2744
When we get scattering results, there is no reason to keep internal
headers any more.
* Fix `ScatterGatherHandler` to modify scattering result messages to
reinstate headers from original request message.
This way we are able to re-throw an exception from the gatherer to
the caller.
* Fix typos and language in Docs
