INT-4542: CorrMH: Use popSequenceDetails properly (#2591)

* INT-4542: CorrMH: Use popSequenceDetails properly

JIRA: https://jira.spring.io/browse/INT-4542

Perform a `MessageBuilder.popSequenceDetails()` for those
`MessageGroupProcessor` results which are not `Message`
or `Collection<Message>`

**Cherry-pick to 5.0.x**

* * Add `AbstractCorrelatingMessageHandler.popSequenceDetails` property

* * Rename property to just a `popSequence`

* * Fix JavaDocs on the `AbstractCorrelatingMessageHandler.setPopSequence()`
* Fix Docs typos and language
* finish the `RouterTests.testNestedScatterGather()`
This commit is contained in:
Artem Bilan
2018-10-10 14:03:40 -04:00
committed by Gary Russell
parent 1595462ce7
commit 0f5cfd4314
15 changed files with 336 additions and 163 deletions

View File

@@ -103,6 +103,13 @@ This method is invoked for aggregating messages as follows:
NOTE: In the interest of code simplicity and promoting best practices such as low coupling, testability, and others, the preferred way of implementing the aggregation logic is through a POJO and using the XML or annotation support for configuring it in the application.
Starting with version 5.1, after processing message group, an `AbstractCorrelatingMessageHandler` performs a `MessageBuilder.popSequenceDetails()` message headers modification for the proper splitter-aggregator scenario with several nested levels.
It is done only if the message group release result is not a message or collection of messages.
In that case a target `MessageGroupProcessor` is responsible for the `MessageBuilder.popSequenceDetails()` call while building those messages.
This functionality can be controlled by a new `popSequence` `boolean` property, so the `MessageBuilder.popSequenceDetails()` can be disabled in some scenarios when correlation details have not been populated by the standard splitter.
This property, essentially, undoes what has been done by the nearest upstream `applySequence = true` in the `AbstractMessageSplitter`.
See <<splitter>> for more information.
[[agg-message-collection]]
IMPORTANT: The `SimpleMessageGroup.getMessages()` method returns an `unmodifiableCollection`.
Therefore, if your aggregating POJO method has a `Collection<Message>` parameter, the argument passed in is exactly that `Collection` instance and, when you use a `SimpleMessageStore` for the aggregator, that original `Collection<Message>` is cleared after releasing the group.

View File

@@ -107,6 +107,9 @@ See <<java-dsl-flows>> for more information.
If the `groupTimeout` is evaluated to a negative value, an aggregator now expires the group immediately.
Only `null` is considered as a signal to do nothing for the current message.
A new `popSequence` property has been introduced to allow (by default) to call a `MessageBuilder.popSequenceDetails()` for the output message.
Also an `AbstractAggregatingMessageGroupProcessor` returns now an `AbstractIntegrationMessageBuilder` instead of the whole `Message` for optimization.
See <<aggregator>> for more information.
[[x5.1-publisher]]