Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.142.190 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:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=kl8gk6BHy5FI1PLOp9rXMB8rJRJpfQG5NlqtTQ5tfrAaKYd9RblLN6d6SThLiKlRY1
         JQuHjWJHUxkZaU5HJ6HthVBsXcderQ5iLtGUBq+EQHcBRF4XwXYBySJ/QzWCLoMeampN
         G69f1lFO7G9mQLQgSmwkLXgceJfOYKgN+it6E=
Message-ID: <499B6D6E.1050609@gmail.com>
Date: Wed, 18 Feb 2009 10:07:42 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: Camel 2.0 - Keys for header problem
References: <5380c69c0902162358m7aa54016v3fbb89a33e968896@mail.gmail.com>
 <eeacbf0c0902170757q5de2507bw83c3cb646af5afba@mail.gmail.com>
In-Reply-To: <eeacbf0c0902170757q5de2507bw83c3cb646af5afba@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I think the component developers should aware these header if they want
to use them in their component.

I have a quick question about this change of camel-cxf component.

As you know cxf message using the dots name as the header key, like the
Message.RESPONSE_CODE, Message.PROTOCOL_HEADERS etc. These headers are
used wildly in camel-cxf component and application user may use them
direly in their processor if they familiar with CXF.

If we want to support the CamelCase style header key in camel-cxf
component.Do we need to extract mapping layer between the camel-cxf
message and cxf message?

I don't know if we can get enough benefits to overcome the inconvenience
of CamelCase style header.

For the JMS , we map the header key with dot separator to slash
separator back and forth in the JMS transport binding layer. And we can
isolate this kind of special in JMS.

Just my 2 cents.

Willem


William Tam wrote:
> I agreed with the convention.  Just one question, are we going to have
> component neutral headers that can be understood by more than one
> component?  If we are, what's the convention and where should they go
> in the source?  The obvious reason is the "interoperability" between
> components.  For example, if I am writing a component that needs to
> understand http headers. my component will then have to check for
> CamelHttpResponseCode and CamelRestletResponseCode to be able to work
> with Http and Restlet components.
> 
> On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> Hi
>>
>> We have a bullet on the Camel 2.0 design page:
>> http://camel.apache.org/camel-20-design.html
>>
>> Bullet:
>> using Camel${component}${name} pattern as header keys instead of using
>> package names with dots that isn't likely to be transported by JMS or
>> other transport types
>>
>> Currently we have mixed content using the old style (using package
>> names) and the new style.
>> What I would like to get done before we have a M1 version is to get
>> this fixed beforehand.
>>
>> As the change involves looking into all components and fixing it one
>> by one it would take some time.
>>
>> If you are in doubt why we should do it, then i will quote what
>> Jonathan wrote on IRC
>>
>> "this is CamelCase style"
>>
>> Well spotted Jon, of course we should have CamelCase in Camel :)
>>
>>
>> Any thoughts?
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>