camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From unmarshall <unmarsh...@gmail.com>
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
endpoint. 

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,
Madhav


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
>>> 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
>>>
>>>
>>>
>>
> 
> 
> -- 
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog:    http://willemjiang.blogspot.com (English)
>           http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> 
> 

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

Mime
View raw message