camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: CfxBinding places custom headers at different places
Date Tue, 25 Jan 2011 07:48:59 GMT
On 1/25/11 2:43 PM, unmarshall wrote:
> Hi Willem,
> Another problem is that we cannot set an Object against a Header and rest
> assured that the object's type would be preserved.

I didn't suggest you to do that.

> There was a recent JIRA that Claus had raised as i had requested him to
> include the ability to add objects as properties/headers. The data type in
> properties is preserved but when it is set as a Header then toString()
> method is called on the object and the String representation of the object
> is stored as the header value.

We use the .toString for the MESSAGE.PROTOCOL_HEADER serialization.
If your customer header is not that kind of header, you'd better to put 
it into the Client.REQUSET_CONTEXT map.

> String representation is true for most of the headers but custom headers
> might have different types which will then be acted upon either by their
> respective handlers or interceptors in case of CXF.

If you customer interceptor can handle it, that will be good.
I don't think current camel-cxf code can do that out of box, but the CXF 
interceptor framework can let you do it :)
> I see this as a limitation.
> Regards,
> Madhav
> unmarshall wrote:
>> 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

Blog: (English)
Twitter: willemjiang

View raw message