Announcement Announcement Module
Collapse
No announcement yet.
Client - SOAP Header Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Client - SOAP Header

    How do I get soap header information in client response? e.g. using webServiceTemplate.sendAndReceive( url, payload, .... )....
    Last edited by msbhalani; May 5th, 2008, 04:05 PM.

  • #2
    Any help....... ?

    Comment


    • #3
      You get get the response header by writing a WebServiceMessageExtractor, see http://static.springframework.org/sp...t.html#d0e3394. Or, you could write a ClientInterceptor.

      Comment


      • #4
        Would this work i.e. SourceExtractor ?

        sendSourceAndReceive(String uri, Source requestPayload, WebServiceMessageCallback requestCallback, SourceExtractor responseExtractor)

        If yes, I do not see/get header information.....

        Thank you.

        Comment


        • #5
          Does anyone have update on this one?

          Comment


          • #6
            Use a ClientInterceptor this way:
            1)Define a request scoped bean and inject it both in the interceptor and your WS client;
            2)in the interceptor read the SOAP Header and unmarshal it to an object using Jibx , JAXB or what you prefer method and set this object as a value of the request scoped bean;
            3)Read the object representing the Header from the request scoped bean in your WS client.

            Luciano

            Comment


            • #7
              Thank you for your reply. I am doing the same thing. But I have a requirement where there is no request scope available i.e. no container, stand alone application....

              Is there other way to do this?

              Comment


              • #8
                When there is not a request scope, I use the same approach with a custom thread scope see also

                http://jira.springframework.org/browse/SPR-2581

                Comment


                • #9
                  Use Threadlocal

                  I had a similar scenario and i use threadlocal to overcome my problem.

                  Essentially, i defined a provider which stores the bean in the threadlocal context. Everybody who needs to access the bean asks the provider for it.

                  Comment


                  • #10
                    That will work.....

                    Comment

                    Working...
                    X