XmlPayloadUnmarshallingTransformer should support Message results [INT-903]

[spring-operator]

Mark Fisher opened INT-903 and commented

This behavior is actually driven by the current base class: AbstractPayloadTransformer. It passes only the payload (not the full Message) to the sub-class' transformPayload(payload) method. It also treats the return value as a new payload even if that subclass method returns a full Message.

The idea is to refactor the method such that it does recognize a Message-typed return value (rather than creating a Message with another Message as its payload). However, we might want to take this one step further, by refactoring this directly into AbstractTransformer and providing a boolean value for whether to pass the Message or the payload as the argument (as in other places in the framework, it could be a boolean property named "extractPayload"). Alternatively, we could have both as protected methods so that subclasses choose which "level" to override.

---

Affects: 2.0 M1

Issue Links:

• XML Marshalling transformer should support Message input as an alternative to the payload [INT-909] #4915 XML Marshalling transformer should support Message input as an alternative to the payload

• Refactor Transformer hierarchy [INT-917] #4924 Refactor Transformer hierarchy

[spring-operator]

Mark Fisher commented

#4924 has been created to track the more general refactoring, but this particular issue is now resolved even if the class itself might undergo some refactoring. A test has been added to avoid any regressions related to this specific issue during such refactoring.