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.
