* 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`
* GH-2695: Add proxy option to @EnablePublisher
Fixesspring-projects/spring-integration#2695
To configure a `proxyTargetClass=true` we need declare a
`PublisherAnnotationBeanPostProcessor` bean manually, but that may cause
a confuse when `@EnablePublisher` is still present.
So, target service is proxied twice
* Expose `proxyTargetClass` and `order` into the `@EnablePublisher`
and `<enable-publisher>`
* Refactor `PublisherAnnotationBeanPostProcessor` to extend an
`AbstractBeanFactoryAwareAdvisingPostProcessor` to avoid AOP boilerplate
code altogether
* Add assertion into the `PublisherAnnotationBeanPostProcessor` to be
sure that only one of its instance is present in the application context
* * Polishing error message and Docs
* Fix BeanFactory propagation for MMInvokerHelper
* Remove check for `null` in the
`MessagingMethodInvokerHelper.isProvidedMessageHandlerFactoryBean()`
* Fix `RecipientListRouter` for `BeanFactory` propagation to the
`Recipient.selector`
* Fix tests for `BeanFactory` population and propagation
* Add `errorChannel` into the `TestUtils.createTestApplicationContext()`
* Fix some Sonar smell, including new reported
* * Restore NPE check for the `BeanFactory` in the
`MessagingMethodInvokerHelper` to avoid breaking changes in the current
point release
* Some other polishing and optimizations in the
`MessagingMethodInvokerHelper`
When we use explicitly `new NullChannel()` in DSL definition, we don't
provide a bean name and just end up with an explicit `nullChannel`
component name in the class.
This way it clashes with the global `errorChannel`, but since instances
are different we get a `BeanDefinitionOverrideException`
* Remove explicit `nullChannel` component name in the `NullChannel` in
favor of the generated name as it is done for any regular beans
* Some internal polishing in the `NullChannel`
* Some polishing in the `IntegrationFlowBeanPostProcessor` to deal with
`NullChannel` as with any other regular `AbstractMessageChannel`s and
generate a proper name for it within the scope of the current
`IntegrationFlow`
Make MessageHandlerMethodFactory injectable into MessagingMethodInvokerHelper
Allow 'handlerMethod' to be overridden
Deprecate HandlerMethodArgumentResolversHolder
Add 'integrationMessageHandlerMethodFactory' property to IntegrationContextUtils
Add test that actually validates that custom resolver gets picked up
* Polishing code style and some code smells
JIRA: https://jira.spring.io/browse/INT-4572
* Add `setOutputChannelName()` contract into the `MessageProducer`
to avoid proxy unwrapping and casting to the `MessageProducerSupport`
* Enable ModifierOrderCheck Checkstyle rule
* Fix violations for `static` and `abstract` modifier
* Remove redundant code in the `TcpNioConnection`
* Mark `connectionFactoryName` as `@Nullable` in the `TcpConnectionSupport`
ctor and its inheritors
* Fix some smells according IDEA suggestions in the affected classes
* This should fix some Sonar smells as well
* * Fix `HeaderMapperTests`
* * Polishing `TcpConnection` code style and fix Javdocs
* INT-4569: Disallow beans override in DSL
JIRA: https://jira.spring.io/browse/INT-4569
* Thorw `BeanDefinitionOverrideException` from the
`IntegrationFlowBeanPostProcessor` when it detects existing bean and it
is not the same object we try to register from the DSL
* Document limitations about `prototype` beans
* Some polishing in the DSL chapter of the docs
* * Fix algorithm in the `IntegrationFlowBeanPostProcessor.noBeanPresentForComponent()`
* * Polishing dsl.adoc
* Call `BeanFactory.initializeBean()` for existing beans if they are
`prototype`
* * Code formatting in the `ManualFlowTests`
* Use Context CL wherever it is applicable
* Use `ClassUtils.getDefaultClassLoader()` in the `IntegrationManagementConfigurer`
for checking a Micrometer presence from the `afterSingletonsInstantiated()`
* Use `ClassUtils.getDefaultClassLoader()` in the `ScatterGatherHandler`
to load required class
* Refactor `HeaderEnricherParserSupport` do not use CL at all.
The `TypedStringValue` will resolve a target type later by the
`BeanFactory`.
This way we honor a property placeholder behavior for the `type` XML
attribute
* * Use `ClassUtils.getDefaultClassLoader()` in the ScatterGatherHandler ctor
