camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From unmarshall <>
Subject Re: CfxBinding places custom headers at different places
Date Tue, 25 Jan 2011 10:47:41 GMT

Hi Willem,

>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.

In future we will have tooling generate Spring XML representing camel route.
In Spring application context XML we can simply add headers using
<camel:setHeader> element. Unfortunately this does not give us control of
where this header should go.

We can do this programmatically but that would involve creating a custom
processor just to set the custom headers before the message goes to the next

If there was a unified approach to storing headers and acting on them later
then <camel:setHeader> was sufficient for handling all sorts of headers.

Best Regards,

Willem.Jiang wrote:
> 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
>>> 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
> -- 
> Willem
> ----------------------------------
> FuseSource
> Web:
> Blog: (English)
>  (Chinese)
> Twitter: willemjiang

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message