Announcement Announcement Module
No announcement yet.
Conversion strategy of jms message type to SI endpoint argument type? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Conversion strategy of jms message type to SI endpoint argument type?


    SI is going great. However I had some interesting behaviour today which is not completely clear to me. I would like your help in understanding it.

    The entry point to my workflow is an asynchronous jms message listener (DMLC). I'm using a jms message driven channel adapter.

    When I send a string message to the queue SI picks it up off the queue and logs that it has dequeued MQTextMessage and then converts it to a GenericMessage.

    Here comes the problem. The next endpoint in the chain accepts an argument of String as the message expected off the queue is a jms TextMessage. At this point SI throws an exception saying that it cannot convert a GenericMessage to a String (no matching editors or conversion strategy found). So I've had to workaround by creating a transformer in between which extracts the message text and returns a string to the next endpoint.

    Where does the jms message type resolution or jms message payload type resolution happen and what are the rules it is following here? Why is SI not creating an SI StringMessage (instead of SI GenericMessage) from the jms MQTextMessage which implements jms TextMessage?

    I can provide xml and code snippets if need be.

    Many thanks.

  • #2
    This most likely has to do with the boolean 'extractPayload' property for the adapter. First, what version of SI are you using?


    • #3
      Hi Mark,

      Thanks for your help.

      I am using 1.0.1 right now.

      I will double check the extractPayload property tomorrow and see if that helps.



      • #4
        Mark. It was the extractPayload property. Somehow I had it set to false. This is now resolved. Sorry for the hassle! Thanks for your help.


        • #5
          No problem! And, just to be clear, you are now just relying on the default? (should not need to provide 'extract-payload' at all since the default should be *true*)



          • #6
            Yes although I have that attribute in there at the moment thanks for reminding me that it is not in fact needed. I guess I wasn't sure if I should leave it in simply for further documentation for others in my team. However there's also the argument that they should read the manual :-)