Simplify AbstractReplyProducingMessageHandler by removing ReplyMessageHolder [INT-901]

[spring-operator]

Mark Fisher opened INT-901 and commented

For example, the definition of the abstract method for subclasses to implement could change from:

protected abstract void handleRequestMessage(Message<?> requestMessage, ReplyMessageHolder replyMessageHolder);

to the following:

/**
 * Subclasses must implement this method to handle the request Message. The return
 * value may be a Message, a MessageBuilder, or any plain Object. The base class
 * will handle the final creation of a reply Message from any of those starting
 * points. If the return value is null, the Message flow will end here.
 */
protected abstract Object handleRequestMessage(Message<?> requestMessage);

---

Affects: 2.0 M1

[spring-operator]

Mark Fisher commented

See the commit log under the "Source" tab for the details of this refactoring.

[spring-operator]

Mark Fisher commented

Reopening since the recent changes cause any ARPMH sub-class to split its reply if that reply is Iterable, whereas only AbstractMessageSplitter and its sub-classes should.