diff --git a/spring-integration-reference/src/splitter.xml b/spring-integration-reference/src/splitter.xml
index 67f51d7a28..22c7927731 100644
--- a/spring-integration-reference/src/splitter.xml
+++ b/spring-integration-reference/src/splitter.xml
@@ -13,17 +13,11 @@
includes an Aggregator.
-
-
Programming model
The API for performing splitting consists from one base class,
- AbstractMessageSplitter, which is a MessageConsumer implementation,
+ AbstractMessageSplitter, which is a MessageHandler implementation,
encapsulating features which are common to splitters, such as filling in
the appropriate message headers CORRELATION_ID, SEQUENCE_SIZE, and
SEQUENCE_NUMBER on the messages that are produced. This allows to track
@@ -50,7 +44,7 @@
a Collection (or subclass thereof) or an array of Message
objects - in this case the messages will be sent as such (after the
- CORRELATION_ID, SEQUENCE_SIZE and SEQUENCE_NUMBER will be populated).
+ CORRELATION_ID, SEQUENCE_SIZE and SEQUENCE_NUMBER are populated).
Using this approach gives more control to the developer, for example
for populating custom message headers as part of the splitting
process.
@@ -60,7 +54,8 @@
a Collection (or subclass thereof) or an array of non-Message
objects - works like the prior case, except that each collection
element will be used as a Message payload. Using this approach allows
- to focus on the
+ developers to focus on the domain objects without having to consider
+ the Messaging system and produces code that is easier to test.
@@ -75,7 +70,9 @@
argument and has a return value. In this case, the return value of the
method will be interpreted as described above. The input argument might
either be a Message or a simple POJO. In the latter case, the splitter
- will receive the payload of the incoming message.
+ will receive the payload of the incoming message. Since this decouples
+ the code from the Spring Integration API and will typically be easier
+ to test, it is the recommended approach.