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.
[1]
https://svn.apache.org/repos/asf/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPConduit.java
's method getSetProtocolHeaders
Just my two cents,
Willem
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
