Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.218.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=fCIpX+vdLmz8oipPxcAnnFAB6rap6rHYZKvt6R3x8ZZahnnQHX/J67Iug9wXldJKuK
         EAUDESA/Jav6cHLSMm7unaivJ+QFsUqR/WQy/KiPPs9S+X7W47XGq2AUdpW/HvlQJnoD
         uypWVNVKsBAFUVsVd6X4edMFMprlh0lhOGI7Q=
Message-ID: <4D3E806B.1010409@gmail.com>
Date: Tue, 25 Jan 2011 15:48:59 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: CfxBinding places custom headers at different places
References: <1295862562597-3354431.post@n5.nabble.com>
 <4D3D6B4E.8090802@gmail.com> <1295874529878-3354593.post@n5.nabble.com>
 <1295937798960-3355841.post@n5.nabble.com>
In-Reply-To: <1295937798960-3355841.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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