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`
* INT-4570: Add MessageCollectionCallback for Mongo
JIRA: https://jira.spring.io/browse/INT-4570
The `MongoDbOutboundGateway` is intended to be used with the
`requestMessage` context, however using a plain `CollectionCallback`
we don't have access to the `requestMessage`
* Deprecate `CollectionCallback` usage in favor of newly introduced
`MessageCollectionCallback` and `message-collection-callback` for XML
**Cherry-pick to 5.0.x**
* * Remove `message-collection-callback` in favor of
`MessageCollectionCallback<T> extends CollectionCallback<T>`
* * Rename a new setter to `setMessageCollectionCallback()` to avoid
reflection collision
* 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`
* RedisLock: Throw exception from unlock on expire
The lock might be expired in target Redis store in between `lock()` and
`unlock()`.
So, throw an `IllegalStateException` when lock is expired during
unlocking.
At the same time the lock lock is unlocked anyway.
**Cherry-pick to 5.0.x**
* * Create a new test for exception
* Add more info into the exception
* 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
https://build.spring.io/browse/INT-MASTERSPRING40-553
The `ImapMailReceiverTests` fails sporadically according some race
condition or wrong logic.
* Fix `ImapIdleChannelAdapter` to check for folder not null before
performing logic in the `IdleTask`
* Polishing for logs which are based on constant strings
* Remove `volatile` from configuration properties in the
`ImapIdleChannelAdapter` and `AbstractMailReceiver`
* Refactor some smells into the `protected` getters instead of direct
access to the property
* Stop channel adapters in the `ImapMailReceiverTests`
* Also destroy task schedulers in the `ImapMailReceiverTests`
* INT-4565: Fix IntComponentScan for profiles
JIRA: https://jira.spring.io/browse/INT-4565
* Propagate an `Environment` to the internal `ClassPathScanningCandidateComponentProvider`
in the `IntegrationComponentScanRegistrar` for proper profiles activation
* Ensure the logic works in the `GatewayInterfaceTests`
* Some polishing and performance improvement for the `GatewayInterfaceTests`
* Add a note about `@Profile` in the `gateway.adoc`
* Polishing for the `gateway.adoc`
**Cherry-pick to 5.0.x & 4.3.x**
* * Add not activated by profile gateway interface into the `GatewayInterfaceTests`
* More `GatewayInterfaceTests` polishing
* Fix typo in the `gateway.adoc`
* Fix Checkstyle violation
JIRA: https://jira.spring.io/browse/INT-4150
* Fix internal `taskScheduler` for destroy in the `ImapMailReceiver`
* Some code style polishing in the `ImapIdleChannelAdapter`
JIRA: https://jira.spring.io/browse/INT-4563
* Add a `MqttDslTests` with the JMX configured to be sure that SI
managed components are registered in JMX properly.
* Also this test covers a Java DSL configuration for MQTT channel adapters
* Some polishing for `AbstractMqttMessageHandler`
* Document Java DSL configuration for the MQTT channel adapters
JIRA: https://jira.spring.io/browse/INT-4564
INT-4550 added an error log when multiple ACMHs were registered with the
same store; the error log logic was incorrect and the error was logged
when the first ACMH was registered.
JIRA: https://jira.spring.io/browse/INT-4385
It is slightly unclear for end-users that `<jms:listener-container/>`
is just a syntax sugar and the real JMS container is created by the
`<jms:listener>` sub-element
* Add a NOTE to the `jms.adoc` to explain such a confuse and what and
how is going to happen if the intention to use a `<jms:listener-container/>`
for Spring Integration channel adapters.
