* INT-4550: Disallow multi aggregators on same MGS
JIRA: https://jira.spring.io/browse/INT-4550
**Cherry-pick to 5.0.x**
* * Introduce `UniqueExpiryCallback`
* Use `UniqueExpiryCallback` in the `AbstractCorrelatingMessageHandler`
* Check for uniqueness in the `AbstractMessageGroupStore`
* Remove duplicate code in the `ConfigurableMongoDbMessageStore`
* * Fix tests according a new logic
* * Address PR review
* Change `Assert.isTrue` to the `logger.error` for backward compatibility
* Revert changes in tests since we don't throw exception anymore
* Fix language on doc
* * Fix Checkstyle violation in the `AbstractMessageGroupStore`
* * Ignore `testDontReapMessageOfOtherHandler()`
* Fix wrong import order in tests
* Polishing for not closed application contexts
* Use diamonds
* Use proper assertion operators
* Remove redundant classes
* Improve performance in JPA tests
* Fix typos
https://build.spring.io/browse/INT-FATS5IC-685/
Even if we stop `SourcePollingChannelAdapter`, the task on the fly is
still going to be executed.
This way we may have extra calls to our logic.
* Use `CopyOnWriteArrayList` for the `sessionSources` to avoid
`ConcurrentModificationException` during this collection read in the
tests
**Cherry-pick to 5.0.x**
Starting with version `2.5.0` the `groovy-all` is a BOM.
That is not clear how it works as a regular dependency in our Gradle
config, but generated pom is wrong with this dependency.
(Gradle bug?)
* Specify explicit required dependencies for `spring-integration-groovy`
and `spring-integration-scripting` modules
https://build.spring.io/browse/INT-MASTERSPRING40-511
The `AbstractCorrelatingMessageHandlerTests.testScheduleRemoveAnEmptyGroupAfterConfiguredDelay()`
relies on the `handler.setMinimumTimeoutForEmptyGroups(100);` which may
happen in the scheduled thread before the main thread reaches an
assertion for size
* INT-4322: Log merged global properties on startup
JIRA: https://jira.spring.io/browse/INT-4322
Now we have DEBUG message in logs like this:
```
Spring Integration global properties:
spring.integration.endpoints.noAutoStartup=fooService*
spring.integration.taskScheduler.poolSize=20
spring.integration.channels.maxUnicastSubscribers=0x7fffffff
spring.integration.channels.autoCreate=true
spring.integration.channels.maxBroadcastSubscribers=0x7fffffff
spring.integration.readOnly.headers=
spring.integration.messagingTemplate.throwExceptionOnLateReply=true
```
* Also register a `mergedIntegrationGlobalProperties` bean on a first
`IntegrationContextUtils.getIntegrationProperties()` call to avoid a
new `Properties` object on each call
* * Fix `TestUtils` to register a `BeanDefinition` instead of `registerSingleton()`
and an explicit `afterPropertiesSet()` call
* * Document mentioned changes
* Some polishing for `whats-new.adoc`
* INT-4459: Mention dependencies in the Docs
JIRA: https://jira.spring.io/browse/INT-4459
* Explicitly say what Spring Integration dependency must be included
into the target project for particular protocol components
* * Fix code block wrapping in the `endpoint-summary.adoc`
- change `loadCaptor` to return any existing captor
- make builders and facades protected to allow subclassing
- change `AbstractMeter.getMeter()` to use generics
- add test case demonstrating meter name changes
- docs
* Polishing - PR Comments, and rebase
JIRA: https://jira.spring.io/browse/INT-4530
- implement `DisposableBean` in all meter-aware components
- remove meters in `destroy()`
- manually destroy annotation components created by `registerSingleton()`
- changing these beans to register as bean definitions caused some subtle
initialization side-effects; given we are post-RC, I felt it was too late
to make such a large change
- also CPXAC is not a `GenericApplicationContext`
- hence a bean is registered to destroy them manually
* Rebase; Polishing - PR Comments
* INT-4544: Allow runtime MBeans (un)registered
JIRA: https://jira.spring.io/browse/INT-4544
* Fix `SourcePollingChannelAdapterFactoryBean` to register an
`outputChannelName` into the `SourcePollingChannelAdapter` for late
binding, especially in case of dynamic `IntegrationFlow` registrations.
This must be back-ported to `5.0.x`
* Implement `DestructionAwareBeanPostProcessor` in the
`IntegrationMBeanExporter` for the runtime beans tracking, e.g. via
dynamic `IntegrationFlow` registrations
* Refactor `IntegrationMBeanExporter` for static and dynamic beans
registration and destruction
* Remove unused properties; introduce some new for tracking beans and
their relationship
* * Move `IntegrationMBeanExporter.registerProducer()` after
`postProcessAfterInitialization()`
* Refactor JMX test configurations to reuse MBeanServer as much as
possible and destroy the server whenever it is necessary
* * More JMX tests polishing
* * And more JMX tests polishing
* * `try...catch` in the `IntegrationMBeanExporter.postProcessAfterInitialization()`
to avoid breaking changes for the current GA phase
* Do not unregister those MBeans explicitly which weren't created at
runtime
* * Log ObjectNames in the `MBeanExporterIntegrationTests`
* * Fix `MessageMetricsAdviceTests` to rely on the application context
* Do not use a cst in the `StandardIntegrationFlowContext` for
`BeanFactory`, but an explicit `BeanDefinitionRegistry`
* Extract targets from proxies in the
`IntegrationMBeanExporter.postProcessAfterInitialization()`
* Remove logging in the `MBeanExporterIntegrationTests`
* * Fix `NotificationListeningMessageProducerTests` to reuse existing `MBeanServer`
* * Change JMX `domain` in the `DslMBeanTests` to `dsl` do not clash with
similar in the `foo` in the `MessageSourceTests`
* Use `MBeanServer` bean in the `Int2307Tests`
* Use JUnit 5ctor injection injection in the `MessageMetricsAdviceTests`
* * Fix JMX tests do not reuse existing `MBeanServer` and make them rely
on the server provided by the managed `MBeanServerFactoryBean` which
destroys a server on application context close
* Fix `StoredProcJmxManagedBeanTests-context.xml` to use `MBeanServer`
from the `<context:mbean-server>`
JIRA: https://jira.spring.io/browse/INT-4545
Improve the logic in the `AbstractMethodAnnotationPostProcessor` to
check for existing `MessageHandler` and be sure that we need to register
a `ReplyProducingMessageHandlerWrapper` bean
**Cherry-pick to 5.0.x**
