I've added an issue with a patch : https://issues.apache.org/jira/browse/CAMEL-4515
Regards, Damian. -----Original Message----- From: Richard Kettelerij [mailto:[email protected]] Sent: Friday, 23 September 2011 5:34 AM To: [email protected] Subject: Re: SOAP Headers and spring-ws That was the rationale if I remember correctly. But it's rather hypothetical I agree, so I have no problem changing this if it suits Damian better. Looking forward to the patch. On Thu, Sep 22, 2011 at 7:14 PM, Daniel Kulp <[email protected]> wrote: > On Wednesday, September 21, 2011 9:18:05 PM Damian Harvey wrote: > > We have a small issue with the way that the SpringWebserviceConsumer > > retrieves SOAP Headers. > > > > 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 > > > > Aside from being a *nasty* key this breaks the consistency of > > headers in > a > > Route. > > > > I'd like to propose that the extractSoapHeadersFromWebServiceMessage > method > > in the SpringWebserviceConsumer is modified to use the > > getLocalPart() method instead, as I can't think of a use case where > > you want the key prefixed with the namespace. > > The only thing I can really think of is if the soap message has multiple > headers with the same local name but different namespaces. Likely a > very > rare occurrence though. > > > Dan > > > > > > > If this sounds ok I'll submit a patch. > > > > Thanks, > > > > Damian. > > > > > > ________________________________ > > > > This communication (and any attachments) is directed in confidence > > to the > > addressee(s) listed above, and may not otherwise be distributed, > > copied > or > > used. The contents of this communication may also be subject to > privilege, > > and all rights to that privilege are expressly claimed and not > > waived. If you have received this communication in error, please > > notify us by reply e-mail or by telephone and delete this > > communication (and any > attachments) > > without making a copy. > > > > Before opening or using attachments, you should check them for > > viruses > and > > defects. We do not accept liability in connection with computer > > virus, > data > > corruption, delay, interruption, unauthorised access or unauthorised > > amendment. > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com > This communication (and any attachments) is directed in confidence to the addressee(s) listed above, and may not otherwise be distributed, copied or used. The contents of this communication may also be subject to privilege, and all rights to that privilege are expressly claimed and not waived. If you have received this communication in error, please notify us by reply e-mail or by telephone and delete this communication (and any attachments) without making a copy. Before opening or using attachments, you should check them for viruses and defects. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment.
