+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/
