Re: Camel 2.0 - Keys for header problem
Hi I am working on this now, to change it to CamelCase. I am adding xxxConstants classes to the component where we can put the constants for the key names. This allows end users to easy spot which keys we have. I decided for xxxConstants over Constants when end users work with multiple components and want to import Constants then there is a ambiguity. Hence the component prefix, eg. JmsConstants, HttpConstants And in the future we could merge them into a org.apache.camel.Constants or org.apache.camel.Keys class. In the core the keys are stored on the Exchange that William started with. We can later decide if we want a Constants class as well, or whatever. The values for the keys will be changed to use the new CamelCase syntax. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Wed, Feb 18, 2009 at 3:07 AM, Willem Jiang willem.ji...@gmail.com wrote:
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
How do you handle sending SOAP over JMS that CXF support? Do you do
any tricks there as well to conform to the JMS spec?
I do think that any header we expose/set in Camel should be the
CamelCase style. Then whatever other framework does is that framework
choice.
But yeah its some task to look into each and every component and fix
it to the new style.
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.ib...@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/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
On Tue, Feb 17, 2009 at 4:57 PM, William Tam email.w...@gmail.com 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.
I think each component should keep the headers in its own namespace.
So yeah you component should check for both.
In fact it can probably just check for endsWith(ResponseCode) to
cater for different prefixes.
On Tue, Feb 17, 2009 at 2:58 AM, Claus Ibsen claus.ib...@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/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - Keys for header problem
+1 on the new header convention.
It may be hard to get all components in line right away but I'd say having
camel-core use the new header style first would be a big +. We can fix other
components as we see fit/get time.
On Wed, Feb 18, 2009 at 9:21 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Wed, Feb 18, 2009 at 3:07 AM, Willem Jiang willem.ji...@gmail.com
wrote:
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
How do you handle sending SOAP over JMS that CXF support? Do you do
any tricks there as well to conform to the JMS spec?
I do think that any header we expose/set in Camel should be the
CamelCase style. Then whatever other framework does is that framework
choice.
But yeah its some task to look into each and every component and fix
it to the new style.
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.ib...@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/
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
--
Cheers,
Jon
http://janstey.blogspot.com/
