Camel
  1. Camel
  2. CAMEL-4515

Spring-WS should populate Camel Header with the SOAP Header

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.8.1
    • Fix Version/s: 2.11.1, 2.12.0
    • Component/s: camel-spring-ws
    • Labels:
      None
    • Patch Info:
      Patch Available
    • Estimated Complexity:
      Unknown

      Description

      Currently the Camel-Spring-WS component does not support the setting of SOAP Headers and has issues getting them. The current issue getting the SOAP Headers when receiving a message is that the resulting header key includes the namespace.

      Change the component so that a Camel header "CamelSpringWebserviceSoapHeader" can be populated with an intended SOAP Header for a request, and that this Header is also populated from the SOAP Header on a response.

      1. CAMEL-4515.2.patch
        16 kB
        Damian
      2. CAMEL-4515.1.patch
        15 kB
        Damian

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          570d 2h 30m 1 Claus Ibsen 27/Apr/13 07:48
          Hide
          Lucas Smith added a comment -
          Show
          Lucas Smith added a comment - There is a workaround on Spring-WS side: http://leakfromjavaheap.blogspot.com/2014/05/multiple-soap-headers-in-apache-camels.html .
          Hide
          Lucas Smith added a comment - - edited

          Guys, the lack of the possibility to inject a custom XmlConverter (or even a custom TransformerFactory into XmlConverter) is a big limitation. I cannot create a SOAP header with multiple nodes:

          <soap-env:Header>
          <MyFirstHeader>...</MyFirstHeader>
          <MySecondHeader>...</MySecondHeader>
          </soap-env:Header>
          

          I can only have 'one-child-node' SOAP header. The current implementation just performs identity transformation which blindly copies the content of Camel's SOAP header into <soap-env:Header>. It can be resolved with a custom Transformer with XSLT. However, I cannot set that custom Transformer because I cannot inject a custom TransformerFactory because XmlConverter is 100% static.

          Show
          Lucas Smith added a comment - - edited Guys, the lack of the possibility to inject a custom XmlConverter (or even a custom TransformerFactory into XmlConverter) is a big limitation. I cannot create a SOAP header with multiple nodes: <soap-env:Header> <MyFirstHeader>...</MyFirstHeader> <MySecondHeader>...</MySecondHeader> </soap-env:Header> I can only have 'one-child-node' SOAP header. The current implementation just performs identity transformation which blindly copies the content of Camel's SOAP header into <soap-env:Header>. It can be resolved with a custom Transformer with XSLT. However, I cannot set that custom Transformer because I cannot inject a custom TransformerFactory because XmlConverter is 100% static.
          Richard Kettelerij made changes -
          Link This issue is duplicated by CAMEL-5669 [ CAMEL-5669 ]
          Hide
          Matt McCann added a comment -

          Thanks for resolving this. Much appreciated.

          Show
          Matt McCann added a comment - Thanks for resolving this. Much appreciated.
          Claus Ibsen made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Claus Ibsen added a comment -

          Thanks for the patch.

          I added a little bit of docs.

          We can revisit the static XmlConverter later.

          Show
          Claus Ibsen added a comment - Thanks for the patch. I added a little bit of docs. We can revisit the static XmlConverter later.
          Claus Ibsen made changes -
          Fix Version/s 2.11.1 [ 12323967 ]
          Fix Version/s 2.12.0 [ 12323968 ]
          Claus Ibsen made changes -
          Assignee Willem Jiang [ njiang ] Claus Ibsen [ davsclaus ]
          Hide
          Claus Ibsen added a comment - - edited

          It should NOT use that static XML converter directly, but use the camel's type converter.
          But that's not so easy to avoid. Ideally the component should keep an instance of the xml converter, so we don't have static anymore.

          Show
          Claus Ibsen added a comment - - edited It should NOT use that static XML converter directly, but use the camel's type converter. But that's not so easy to avoid. Ideally the component should keep an instance of the xml converter, so we don't have static anymore.
          Hide
          Matt McCann added a comment - - edited

          I suppose it was just wishful thinking. I've got a project that's due next week that needs this functionality so I'll take up the task of finishing the patch.

          EDIT: What exactly was wrong with this patch?

          Show
          Matt McCann added a comment - - edited I suppose it was just wishful thinking. I've got a project that's due next week that needs this functionality so I'll take up the task of finishing the patch. EDIT: What exactly was wrong with this patch?
          Hide
          Christian Müller added a comment -

          Not yet as you can see on the ticket status. It's still open/unresolved.

          Show
          Christian Müller added a comment - Not yet as you can see on the ticket status. It's still open/unresolved.
          Hide
          Matt McCann added a comment -

          Claus, was this patch ever deployed? I'm not seeing the header definition constants in 2.11-SNAPSHOT.

          Show
          Matt McCann added a comment - Claus, was this patch ever deployed? I'm not seeing the header definition constants in 2.11-SNAPSHOT.
          Willem Jiang made changes -
          Assignee Willem Jiang [ njiang ]
          Damian made changes -
          Attachment CAMEL-4515.patch [ 12497747 ]
          Damian made changes -
          Attachment CAMEL-4515.1.patch [ 12500602 ]
          Damian made changes -
          Attachment CAMEL-4515.2.patch [ 12502071 ]
          Hide
          Damian added a comment -

          I took out the populating of the headers as I thought that it would be more consistent to have one way of writing/reading headers. On reflection it reduces the usability so I've put that back in. What are your thoughts on setting the Exchange Header? Should it be a collection of Source or maybe a single Source from the header level? I've implemented the latter.

          I've modified the transformation to use a static XmlConverter. Is this the correct way to use this?

          Attached is an updated patch.

          Show
          Damian added a comment - I took out the populating of the headers as I thought that it would be more consistent to have one way of writing/reading headers. On reflection it reduces the usability so I've put that back in. What are your thoughts on setting the Exchange Header? Should it be a collection of Source or maybe a single Source from the header level? I've implemented the latter. I've modified the transformation to use a static XmlConverter. Is this the correct way to use this? Attached is an updated patch.
          Hide
          Claus Ibsen added a comment -

          Is there a reason why you do not populate the header with the headers from the soap header? To make these headers easily avaiable for end users?

          Also you create a new transformer when you transform the soap header. Is it not better to use some Camel type converter or re-use the transformer to avoid creating a new instance all the time.

          Show
          Claus Ibsen added a comment - Is there a reason why you do not populate the header with the headers from the soap header? To make these headers easily avaiable for end users? Also you create a new transformer when you transform the soap header. Is it not better to use some Camel type converter or re-use the transformer to avoid creating a new instance all the time.
          Hide
          Damian added a comment -

          Please disregard the first patch : CAMEL-4515.patch and instead use CAMEL-4515.1.patch

          Show
          Damian added a comment - Please disregard the first patch : CAMEL-4515 .patch and instead use CAMEL-4515 .1.patch
          Damian made changes -
          Attachment CAMEL-4515.1.patch [ 12500603 ]
          Hide
          Damian added a comment -

          This time with license

          Show
          Damian added a comment - This time with license
          Damian made changes -
          Attachment CAMEL-4515.1.patch [ 12500602 ]
          Hide
          Damian added a comment -

          Updated patch to include setting of SOAP Headers and well as updating how they are retrieved.

          Show
          Damian added a comment - Updated patch to include setting of SOAP Headers and well as updating how they are retrieved.
          Damian made changes -
          Description Currently the Camel-Spring-WS component does not support the setting of SOAP Headers and has issues getting them.

          Change the component so that a Camel header "CamelSpringWebserviceSoapHeader" can be populated with an intended SOAP Header for a request, and that this Header is also populated from the SOAP Header on a response.
          Currently the Camel-Spring-WS component does not support the setting of SOAP Headers and has issues getting them. The current issue getting the SOAP Headers when receiving a message is that the resulting header key includes the namespace.

          Change the component so that a Camel header "CamelSpringWebserviceSoapHeader" can be populated with an intended SOAP Header for a request, and that this Header is also populated from the SOAP Header on a response.
          Damian made changes -
          Summary Spring-ws Consumer keeps SOAP Header namespace when populating Camel Headers Spring-WS should populate Camel Header with the SOAP Header
          Patch Info Patch Available [ 10042 ]
          Description SOAP Headers must be namespace qualified (http://www.w3schools.com/soap/soap_header.asp), and when the Consumer extracts the SOAP headers to populate the Exchange Headers it uses the QName.toString() method. This results in a headers key like :

          {http://mynamespace.url}MyHeaderKey

          The SpringWebserviceConsumer should be modified to use the QName.getLocalPart() method instead so that the Camel Header is (for example) "MyHeaderKey".
          Currently the Camel-Spring-WS component does not support the setting of SOAP Headers and has issues getting them.

          Change the component so that a Camel header "CamelSpringWebserviceSoapHeader" can be populated with an intended SOAP Header for a request, and that this Header is also populated from the SOAP Header on a response.
          Damian made changes -
          Attachment CAMEL-4515.patch [ 12497747 ]
          Hide
          Damian added a comment -

          Patch including change + unit test.

          Show
          Damian added a comment - Patch including change + unit test.
          Damian made changes -
          Field Original Value New Value
          Description SOAP Headers must be namespace qualified (http://www.w3schools.com/soap/soap_header.asp), and when the Consumer extracts the SOAP headers to populate the Exchange Headers it uses the QName.toString() method. This results in a headers key like :

          {http://mynamespace.url}MyHeaderKey

          The SpringWebserviceConsumer should be modified to use the getLocalPart() method instead so that the Camel Header is (for example) "MyHeaderKey".
          SOAP Headers must be namespace qualified (http://www.w3schools.com/soap/soap_header.asp), and when the Consumer extracts the SOAP headers to populate the Exchange Headers it uses the QName.toString() method. This results in a headers key like :

          {http://mynamespace.url}MyHeaderKey

          The SpringWebserviceConsumer should be modified to use the QName.getLocalPart() method instead so that the Camel Header is (for example) "MyHeaderKey".
          Damian created issue -

            People

            • Assignee:
              Claus Ibsen
              Reporter:
              Damian
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development