I am personall against the added map idea. I think the separation is
based on headers that need to be propagated (properties) vs headers
that don't. It would we the endpoint+policy responsibility to decide
what gets propagated. All other distinctions can be made based for
instance on the naming convention of the property.
Hadrian
On Jan 26, 2009, at 1:52 PM, William Tam wrote:
On Mon, Jan 26, 2009 at 9:37 AM, 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.
I think this is inline with the idea of separating user headers in a
different header map in Camel message. The different is now user
headers go into the exchange rather than the "user header" map. I
guess same issue could apply to this approach. That is, the
distinction of user/system/protocol header is not always clear. I
think it is a bit overall simplified to neglect headers that a
endpoint creates but do not get sent to in the protocol message. I
think we agree that system headers should not be propagated. So,
they can't go to the exchange (otherwise they get copied in the
pipeline case) and they are not protocol headers.
If pipeline copies exchange properties rather than headers, we can
avoid protocol headers getting copied (sometime, we do want to
propagate protocol header. see below). But, we can achieve it with
the "separating user header in a different map" approach as well.
Exchange properties do not address the "system header" getting
unnecessarily propagated. Sure, it has downside, but I think sending
message with worrying about exchange properties is a win for the
users.
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,
It is desirable to allow protocol header propagation between
endpoints. Mostly for user-defined headers.
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()).
In turns of functionality, header has out direction but exchange
property do not. So, it imposes a restriction that the out direction
(non-protocol) header has to have a different prop name than the in
direction.
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.
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/
