Announcement Announcement Module
Collapse
No announcement yet.
Soap Message Mime Headers Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Soap Message Mime Headers

    I'm consuming a web service which has a login method that needs to be called before sending any further requests. The login method response has a MimeHeader called "Set-Cookie" and the value of this header needs to be added as a request MimeHeader called "Cookie" to the subsequent requests. So my question is.........how can I do this in Spring Integration

    So far my solution involves too much custom code for my liking. I've created a message extractor that looks for the "Set-Cookie" mime header and adds it as a SI message header and used that as the message extractor for the SimpleWebServiceOutboundGateway that calls the login method. Then I've had to create a request call back that takes the SI header and sets it as a MimeHeader on the outgoing SoapMessage for the other SimpleWebServiceOutboundGateway. The biggest problem is that request callbacks don't have access to the SI message. The only one that could is the private one that deals with SoapActions actually in the SimpleWebServiceOutboundGateway class. So, I've had to override this class in my app with my own version which obviously is not good!

    Do you have any suggestions of what else I could do?

  • #2
    I think your use-case would provide valuable input for this issue (currently planned for 2.0.2): https://jira.springsource.org/browse/INT-1532

    Comment


    • #3
      Something really strange has happened. I stripped out all the custom code to start again and look for a neat solution. So I basically have the ws outbound gateway using the namespace with the uri and message sender set. My message sender is HttpCommonsMessageSender with just the connection timeout set. I have 2 of these gateways in the chain, 1 does the login method and the other does the method I want to call. And it works! Something somewhere must be taking the set-cookie from the first call and then adding it to the subsequent requests. I haven't debugged it to see what's doing it but my guess is the message sender. Guess I could easily swap this out to see.

      Comment


      • #4
        Indeed, CommonsHttpMessageSender is doing it. It's probably always done it and I never realised, doh!

        Comment

        Working...
        X