* Short-circuit methods for lambdas from annotation
When we have a `@ServiceActivator` or any other messaging annotations
on `Function` or `Consumer` `@Bean`s, there is a restriction when we
can't use lambdas because of target method argument type erasure in Java.
* Use a `@Bean` method return to determine the target function argument
type and wrap the call into the `LambdaMessageProcessor`.
In this case we call the target method directly after possible payload
conversion according expected generic type for `Function` or `Consumer`.
There is just no reason to go a `MessagingMethodInvokerHelper` route
for this lambda variants
* Apply the short-circuit algorithm for Kotlin lambdas as well
* Make some refactoring and improvements to `ClassUtils`
if favor or similar API in the SF `ClassUtils`
* Fix `No beanFactory` warning for the `ExpressionCommandMessageProcessor`
* * Resolve Checkstyle violations
* * Fix `resolveAttributeToBoolean()` argument name to be generic
* Fix typo in the exception message for `IntegrationFlowDefinition.get()`
* * Revert `ClassUtils.resolvePrimitiveType()` logic: an existing in SF
does exactly opposite one
* Do not fix urls for the `http://apache.org/xml/features` when we
configure XML components
* Do not fix urls for localhost and fake links in tests
* Fix all the dead links in docs
* 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`
* 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`
* 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`
* 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()`
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
* Use `IntegrationUtils.wrapInHandlingExceptionIfNecessary()` whenever
it is possible to avoid double wrapping into the `MessageHandlingException`
* Some code polishing for affected classes `@Nullable`, streams, diamonds etc.
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/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
* Introduce `JavaUtils` for chaining properties setting
* Fix method complexity in the `ServerWebSocketContainer` using newly
introduced `JavaUtils`
* Make `JavaUtils` as `final`
Fixes https://github.com/spring-projects/spring-integration/issues/2731
When we have a nested gateway configuration, we are losing the context
of the current request message in case of errors and the downstream
`MessagingException` is just re-thrown as is, without the proper
`failedMessage` and its processed `errorChannel` header.
* Check for exception type and for the `errorChannel` header in the
current `requestMessage` before re-throwing as a new
`MessageHandlingException` in the `MessagingGatewaySupport.sendAndReceive()`
* Extract `.gateway()` tests into the separate `GatewayDslTests` class
* Add default expressions for ExpEvalReqHAdvice
https://stackoverflow.com/questions/54546728/how-to-handle-ftpoutboundadapter-connection-exception-in-spring-integration-flow
When channels are configured for the `ExpressionEvaluatingRequestHandlerAdvice`,
but no expressions, the logic is not performed.
In other words: we can evaluate expressions, when no channels,
but we don't send messages to channels when no expressions.
* Provide default expressions to be evaluated to `payload`, when only
channels are provided.
* * Remove asserts for expression setters
Fixes https://github.com/spring-projects/spring-integration/issues/2733
`AbstractMessageChannel` exception meters caused a memory leak because they
are stored in a `Set` for destruction purposes but did not implement
`hashCode` and `equals`.
Add `hashCode()` and `equals()` to all meter facades, delegating to the
underlying Micrometer objects.
JIRA: https://jira.spring.io/browse/INT-4386
* Expose `java.time` in the `IntegrationEvaluationContextFactoryBean`
ot simply a `T()` SpEL operator
* Add `Instant` result evaluation to the `delayExpression`
* Make IOS.setTaskScheduler() as public
* Make `IntegrationObjectSupport.setTaskScheduler()` as `public` and
remove all the overrides for visibility
* Fix Sonar smells for all the affected classes
* * Fix `throws Exception` for affected classes to avoid compilation errors
* * Fix "merely rethrow" smell
* Revert `throws Exception` for `AbstractEndpoint.destroy()`
* * Catch a couple exceptions from `destroy()`
Since an `IntegrationComponentSpec` is a `FactoryBean`, all it's target
callbacks and lifecycle is controlled over a `FactoryBean`.
* Add `SmartLifecycle` for the `IntegrationComponentSpec` to delegate
lifecycle hooks to the `target` if necessary
* Refactor `IntegrationComponentSpec` to be an `AbstractFactoryBean`
which is a central place for the `FactoryBean`, `InitializingBean` and
`DisposableBean` interfaces
**Cherry-pick to 5.0.x**
* Fix DSL to deal with beanNames for handlers
When consumer endpoint is created by the Framework, the target
`MessageHandler` gets a `componentName` from the `ConsumerEndpointFactoryBean`.
Therefore we can't rely on the `getComponentName()` when we create beans
from Java DSL.
* Introduce `NamedComponent.getBeanName()` contract; make it default
to the `getComponentName()`; implement this method from the
`IntegrationObjectSupport`
* Use this new `getBeanName()` from the `IntegrationFlowBeanPostProcessor`
and `StandardIntegrationFlowContext` for better existing beans checks
and possible reuse existing `MessageHandler` in different endpoints
* Optimize `FixedSubscriberChannel` and implement `getBeanName()` over there
* Implement `getBeanName()` in the `AbstractMessageSource`; use
`ExpressionEvalMap` to evaluate headers expressions
* Implement `getBeanName()` in `Trackable*Metrics` classes as delegation
to the `this.trackable`
* * Fix race condition around `discardChannelName` property in the `MessageFilter`
