You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by unmarshall <un...@gmail.com> on 2011/01/24 10:49:22 UTC
CfxBinding places custom headers at different places
Hi,
I am trying to set custom headers on a camel message. Now when this message
gets converted to Cxf message and becomes a part of the CxfExchange then the
custom headers are put into the Cxf message depending on the DataFormat
(Payload/Message/Pojo).
For Payload the headers are placed under PROTOCOL_HEADERS
For POJO i guess it is placed under SOAP headers
For Message headers i guess the message is a SOAP message so it should go as
part of the SOAP header (not sure).
The point is that the extraction of headers during the invocation of the CXF
interceptor chain becomes then coupled with the DataFormat and makes it
unnecessarily complex.
This is not the case when custom properties are added to the Camel exchange.
All custom properties then available under INVOCATION_CONTEXT /
REQUEST_CONTEXT and that behavior is common and not dependent on the
DataFormat of the messages contained inside the exchange.
Is there a cleaner way to place the custom message headers in only one
place?
Best Regards,
Madhav
--
View this message in context: http://camel.465427.n5.nabble.com/CfxBinding-places-custom-headers-at-different-places-tp3354431p3354431.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CfxBinding places custom headers at different places
Posted by unmarshall <un...@gmail.com>.
Hi Willem,
>You can override the DefaultCxfBinding by putting your custom header
>into the CXF message. camel-cxf component support you to set a custom
>CxfBinding from URI with the option like this "cxfBinding=#bindingName ".
>
>Then you don't need add other custom processor into the route.
Yes that solved the problem and is somewhat cleaner than other approaches.
Another approach would be to introduce a hook to handle / manipulate message
headers / exchange properties at any point, similar to the way you have a
hook to filter message headers using HeaderFilterStrategy.
Thanks & Regards,
madhav
--
View this message in context: http://camel.465427.n5.nabble.com/CfxBinding-places-custom-headers-at-different-places-tp3354431p3360995.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CfxBinding places custom headers at different places
Posted by Willem Jiang <wi...@gmail.com>.
On 1/25/11 6:47 PM, unmarshall wrote:
>
>
> 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.
You can override the DefaultCxfBinding by putting your custom header
into the CXF message. camel-cxf component support you to set a custom
CxfBinding from URI with the option like this "cxfBinding=#bindingName ".
Then you don't need add other custom processor into the route.
>
> 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
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: CfxBinding places custom headers at different places
Posted by unmarshall <un...@gmail.com>.
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.
Re: CfxBinding places custom headers at different places
Posted by Willem Jiang <wi...@gmail.com>.
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
Re: CfxBinding places custom headers at different places
Posted by unmarshall <un...@gmail.com>.
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.
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.
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.
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
>
>
>
--
View this message in context: http://camel.465427.n5.nabble.com/CfxBinding-places-custom-headers-at-different-places-tp3354431p3355841.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CfxBinding places custom headers at different places
Posted by Willem Jiang <wi...@gmail.com>.
On 1/24/11 9:08 PM, 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.
>
It's more like a CXF extension instead of a Camel extension.
> 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.
What kind message header are you using?
I think we just make sure some camel-cxf header can be copied directly
into cxf message, so you will not face this kind of issue again.
Currently we just copy the Message.PROTOCOL_HEADERS and
Client.REQUEST_CONTEXT into the CXF message from Camel message or Camel
exchange.
Maybe you can consider to put your Customer header into a map and set it
with the key of Client.REQUEST_CONTEXT into the message header.
>
>> 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.
CXF API provides a way that you want by letting you set the Client
REQUEST_CONTEXT, I think we should take a best usage of it.
>
> Best Regards,
> Madhav
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: CfxBinding places custom headers at different places
Posted by unmarshall <un...@gmail.com>.
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.
Re: CfxBinding places custom headers at different places
Posted by Willem Jiang <wi...@gmail.com>.
On 1/24/11 5:49 PM, unmarshall wrote:
>
> Hi,
>
> I am trying to set custom headers on a camel message. Now when this message
> gets converted to Cxf message and becomes a part of the CxfExchange then the
> custom headers are put into the Cxf message depending on the DataFormat
> (Payload/Message/Pojo).
>
> For Payload the headers are placed under PROTOCOL_HEADERS
> For POJO i guess it is placed under SOAP headers
> For Message headers i guess the message is a SOAP message so it should go as
> part of the SOAP header (not sure).
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.
>
> The point is that the extraction of headers during the invocation of the CXF
> interceptor chain becomes then coupled with the DataFormat and makes it
> unnecessarily complex.
>
> This is not the case when custom properties are added to the Camel exchange.
> All custom properties then available under INVOCATION_CONTEXT /
> REQUEST_CONTEXT and that behavior is common and not dependent on the
> DataFormat of the messages contained inside the exchange.
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.
>
> 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 .
>
> Best Regards,
> Madhav
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang