NormalizedMessage now can only contain re-readable Source (see PETALSESBCONT-327).
If a Source is mutable, it means that there is an isolation problem between Consumer and Provider.
If they are BytesSource, they are immutable by design.
If they are StreamSource or SAXSource (not with streams but with a systemId pointing to an URL), their content is immutable, but the Source itself can be modified, like adding a stream or changing the systemId.
If they are DOMSource, their content is mutable and the source itself can be modified by changing the Node or the systemId.
We thus have two open questions around the mutability of Source:
- mutability of the Node in a DOMSource
- mutability of the Source itself
The second point is kind of impossible to solve except by forbidding the use of these Source implementation.
The first point is partially solved by making the Node read-only by exploiting a not-so-public API of the implementation of Node from the JVM library (see PETALSESBCONT-327).
Another problem is with code accessing to a Node and wanting to manipulate it, modify it, etc.
If Node was immutable by design, then there would be no problem, but since it is not, it means that the code must be verified everywhere in the components to avoid exception being thrown when a Node is modified.
For now, this is worked around by returning clones by default from getInMessageContentAsDocument() and getInMessageContentAsDocument() in the Exchange implementation of the CDK.
This is not the best for performance and should thus be improved.
Improvement Request
New
Minor
