camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: [PROPOSAL] ProtocolMessage
Date Tue, 24 Jun 2008 14:12:53 GMT
Hi William,

I just checked  that CXF also puts the protocol header as a Object with 
the key Message.PROTOCOL_HEADERS in the CXF message[1]. If you want to 
get the protocol headers of the CXF message, you can retrieve it from 
CxfMessage's getHeader with the Message.PROTOCOL_HEADERS.
There is a shortcoming in your proposal, if the protocol message is 
cased to the default message for some components or processors, the 
{get|set}ProtocolHeader method will never be called.


's method getSetProtocolHeaders

Just my two cents,


William Tam wrote:
> Hi all,
> I may be totally off but, it seems that Camel Message headers are
> being used too liberally.   Some headers are added by components for
> doing their jobs with no intention to send them as protocol headers.
> Some headers are objects/non-string and are not suitable to be sent as
> headers anyway.  When an app reads headers from a message, it does not
> really know whether a header is actually a protocol header or
> something that gets added by Camel.  Likewise, when an app needs to
> set some protocol headers, Message.setHeader() does not seem to
> provide that kind of semantics.  So, I am proposing creating a
> ProtocolMessage class that extends DefaultMessage with these methods:
> /**
>   * Get protocol header.
>   */
> public List<String> getProtocolHeader(String name) {
> }
> /**
>   * Set protocol header
>   */
> public void setProtocolHeader(String name, List<String> value) {
> }
> For example, CxfMessage will extend ProtocolMessage.  If I call
> CxfMessage.getProtocolHeader(), I get the protocol headers in a CXF
> message not the ones that are added by CxfComponent.
> CxfMessage.getHeader() is unaffected.  Other message types may need to
> be updated as well.
> So, what do you think?
> Thanks,
> William

View raw message