Hi Willem,

>What kind of Custom headers do you want to put?
>
>The PROTOCOL_HEADERS is used for the CXF transport such as Http headers, 
>JMS headers. It's unified for different DataFormat, as the message will 
>finally send or receive from the transport layer no matter what kind of 
>Data Format you are choicing.
>
>For the MESSAGE DataFormat, I don't think you can change the SOAP 
>message header by setting the message header, as the SOAP message is not 
>create by camel-cxf component when it is working in this Data Format.

We have a custom protocol which is an extension of SOAP. This protocol sets
custom headers on the message. There are CXF custom interceptors which are
part of the interceptor chain which are registered at the Bus level. When
these interceptors are invoked then these custom headers are looked up.
However these custom headers land up in different places depending on the
message format.

Now having the logic in Cxf interceptors which depends on the DataFormat
results in a tight coupling between Camel and Cxf which IMO not an ideal way
of doing things.

>The REQUEST_CONTEXT is kind of CXF API which is used to set the customer 
>header, and camel-cxf component just pass this context into CXF message. 
>If you don't want other Camel components to access the this kind of 
>customer header, you can do it in that way.

After going through the code i had an impression that properties on exchange
were only stored under INVOCATION_CONTEXT under REQUEST_CONTEXT. The custom
headers that we set never come here.

>>
> >Is there a cleaner way to place the custom message headers in only one
>> place?
>Yeah, we need to think about it :)
>But for now, there are different level of message header that can be set 
>into the Camel message or Camel exchange. We need to go through them and 
>put them into different catalogs .

One way that comes to mind is to put the headers in one place as a Map or
some other data structure and register handler chain which can then be
called to act upon the message when the message is being serialized. So you
delay the decision of placing the headers to the last instead of doing that
as the first step and thereby allowing clean way to access the message /
properties / headers via any interceptor /handler.

Best Regards,
Madhav


-- 
View this message in context: 
http://camel.465427.n5.nabble.com/CfxBinding-places-custom-headers-at-different-places-tp3354431p3354593.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to