camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Components setting data on OUT
Date Mon, 26 Jan 2009 14:44:09 GMT
On Mon, Jan 26, 2009 at 3:37 PM, Roman Kalukiewicz
<> wrote:
> Why don't we talk about exchange properties here? My feeling here is
> that properties should be used as user-headers, while headers are
> always protocol headers. In fact it works this way right now: If I
> want to keep some value through the whole flow I put it into
> properties.
> By current convention if I put something on a header it is sent as
> protocol-specific header (JMS property, HTTP header), and out headers
> are filled also with protocol headers (JSM properties of out emssage,
> HTTP response headers). In this case headers shouldn't be propagated,
> as there is no way to distinguish things propagated, from things
> retrieved. And out headers ARE different than in headers.
> It is a matter of naming, but currently headers are (what you call)
> protocol/system headers, while properties are user-headers (work as
> variables). Do we really need to extend it further? If someone mix
> those two concepts then it is problem of documentation, but not lack
> of functionality. I would just extend DSL a little to be able to
> retrieve a property (instead using header()).
> What do you think, guys? Maybe we should clearly communicate what
> things are for and what are the consequences of using one or another.
> Roman
> PS. Pipeline should propagate all headers of course, but I believe an
> endpoint is a place where we shouldn't guarantee that headers will be
> propagated by stating it clearly.

Properties have just lived in the dark and end users does not really
know they exists. We have some builder methods to set/get properties.
I guess we need to document and maybe make sure the Spring DSL also
has support for accessing properties as well.

To my knowledge properties is always preserved so I doubt we have an
issue there.

So users should just start learn using properties as well :)
However then we have the ProducerTemplate that has one liners for
sending an Exchange. We dont have a sendBodyAndProperties method. But
yet again it has too many methods already. They can just use
send("xxx", Exchange) and have exchange populated with the properties
of choice.

> 2009/1/26 Claus Ibsen <>:
>> On Sat, Jan 24, 2009 at 9:08 PM, William Tam <> wrote:
>>>> What we have stored in Headers today in Camel is both:
>>>> - user headers
>>>> - and system headers (added by Camel itself).
>>>> I am starting to be more and more convinced that we should separate the two.
>>>> So any headers that a users has enforced to be set should be kept in
>>>> one Map and the others that the components set internally (such as SQL
>>>> number of rows returned, or whatnot we have, there are many) in
>>>> another Map.
>>> It means that a component would have to look for header in more than
>>> one place.   Besides, the distinction of user vs system header is not
>>> always clear.  For example, the operation name header for cxf endpoint
>>> can be set by user but it is also created by cxf component.   I am
>>> sure there are many more examples.  There is another header category:
>>> protocol headers.  A protocol header is not really a user or system
>>> header.  Protocol headers are header propagated from protocol like
>>> HTTP, which we do want to preserve in message header.
>>>> The user headers is always preserved and copied along in the routing.
>>>> User can always clear/remove unwanted headers.
>>>> The system headers should be short lived as they are not really
>>>> useable. So they are "alive" in the next step (process) in the route,
>>>> and when the pipeline invokes next route thereafter these information
>>>> is cleared.
>>>> Separating these will also make the routing/tracing a bit easier as
>>>> Users can recognize their own headers instead its mixed with all the
>>>> noise the Camel components add.
>>> I wonder we can leverage/extend the HeaderFilterStrategy mechanism.
>>> Currently, it is only used for filtering unwanted headers (in both
>>> request and response direction) when we propagate headers between
>>> Camel and external messages (like HTTP).   HeaderFilterStrategy is (or
>>> will be) associated with an endpoint.  We could make
>>> HeaderFilterStrategy available to the exchange object.  So, when an
>>> endpoint creates an exchange, the exchange gets a header filter
>>> strategy.  Then, pipeline can do something like this to filter
>>> unwanted header: message.filterHeaders().   The header filter strategy
>>> is highly customizable for each endpoint (can have a component wide
>>> default) and it can be looked up from registry.
>> Good pointers William.
>> Yeah we can revist it after you have moved the header filters to the endpoint.
>> Then we can check up upon how to leverage it as you suggest.
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> Open Source Integration:
>> Blog:

Claus Ibsen
Apache Camel Committer

Open Source Integration:

View raw message