Yeah, I sent a follow-up message saying that. Do you absolutely require that the breadcrumb's match between the proxy and your web service?
On Tue, Feb 10, 2015 at 12:16 PM, rsteppac2 <[email protected]> wrote: > James, > > sorry, I did not want to make the impression of lightheartedly dismissing > your hint with the BasicMessageFilter. I have extended from it and have > overridden the method to not filter any headers. As suspected this is too > late in the chain. By the time the filter is called the route has already > been processed. > > I tried to find a hook where I could jump in and make the breadcrumbId from > the HTTP headers available. But I am stuck. > > The spring-ws endpoint (SpringWebserviceConsumer) does not care at all about > HTTP headers, only about SOAP headers and properties of the > org.springframework.ws.context.MessageContext. SOAP headers get converted > into exchange headers while message context properties get converted into > exchange properties. Properties could be added by using a > org.springframework.ws.server.EndpointInterceptor. > > A breadcrumbId property is not picked up. Instead the > org.apache.camel.impl.DefaultUnitOfWork creates a new breadcrumbId because > it only checks the in-message headers, not the exchange properties. > A SOAPHeader "breadcrumbId" is copied over to the in-message headers and > actually picked up by the DefaultUnitOfWork, but it is of type > org.springframework.ws.soap.saaj.SaajSoapHeaderElement, which has no > toString() implementation. > > So far so inconvenient... > > Ralf > > PS: I am back in the office on Friday > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762572.html > Sent from the Camel - Users mailing list archive at Nabble.com.
