2009/1/26 Claus Ibsen <claus.ib...@gmail.com>:
> 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.
In fact I believe if you ever did some more complicated thing with
Camel you just had to discover them, as there is no other way to
preserve some information on endpoint (HTTP, JMS in particular)
boudrary.
> To my knowledge properties is always preserved so I doubt we have an
> issue there.
That is the point - they are set on the exchange so no problem exists
as long as pipeline propagates them.
> 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.
This would be also my choice. After all endpoints should care ONLY
about headers - then we make the distinction clear. As producer
template sends messages to _endpoints_ it should (by default) send
mainly headers. So while it could be usefull to have
'sendBodyAndProperties()' in some cases (sending to seda or direct) it
shouldn't be a rule.
So if you want to send some value through JMS (even if it is in
property already) you should set it as a header first. It makes things
a little harder, but then it is clear what happens really.
The problem is that current notation is unfortunate now if you want to
set a header to a value of property, because what you have to do is
setHeader("foo", header("foo"))
while it should be
setHeader("foo", property("foo"))
Roman
>>
>> 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/
>
