On Mon, Jan 26, 2009 at 3:37 PM, Roman Kalukiewicz
<roman.kalukiew...@gmail.com> 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 <claus.ib...@gmail.com>:
>> On Sat, Jan 24, 2009 at 9:08 PM, William Tam <email.w...@gmail.com> 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: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
