Announcement Announcement Module
No announcement yet.
Propagating Message Header properties Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Propagating Message Header properties

    Hey Mark,
    we are trying to resolve some things around JMS messages. We need to set and read the JMS correlation ID, and I see that to do this we need to use a property (rather than the si correlation itself). Why is it that the JmsAdapter does not propagate the incoming correlation Id as the SI correlation Id? What is the point of correlation Id?

    We also need to parse the incoming payload into an XmlBeans object - so it would be useful to be able to set a payload on a message. Right now, we have to construct a new message, and propagate the header across into the new message - passing hte header into the constructor of the new message only copies the properties and attributes. That is not really a copy.

    Can you explain the thought process behind these things, as they were not intuitively obvious to us. I would assume a copy copies all fields, and a correlation id would get captured in the SI field too.


  • #2
    The "correlationId" property in the MessageHeader is used within Spring Integration - specifically for ResponseCorrelator in request-reply situations and also the aggregator. Basically the role is the same as a JMS correlationId, but that particular value is not related to JMS. For adapters in general, relevant values are stored-to and retrieved-from the header properties (same applies for Files, Mail, etc.) The reason that the SI correlationId is not copied is that it's value is determined within the message endpoint's reply handling code. With regard to the setPayload method on Message, it is becoming clear that we should probably provide that. The original idea was to enforce immutability, but as we build out the general message transformation part of the API, I think it will be necessary to set a Message payload. Also, one of the transformer implementations that we intend to provide will delegate to Spring OXM's Marshaller/Unmarshaller interfaces, and that will therefore include XmlBeans support (as well as JAXB, Castor, JibX, and XStream).