Thinking more about it. I agree that things that are not intended to be sent in protocol header should belong to exchange properties not headers. For example, CXF operation name should be a exchange property not a message header. We should adopt some name conventions to avoid property name clashing and improve readability For example, prop name begins with org.apache.camel.<component> are the processed by <component>. And, tmp.org.apache.camel.<component> are property created by component that are not intended to be propagated. I think it addresses the issues of preserving the user header/property, and filtering "system" headers.
Users can send messages with custom protocol headers (using header in the message). In a pipeline, we need to copying exchange properties, message headers and body. For protocol headers, I think we still need to apply some filtering strategy to make sure only the wanted header are propagated. On Mon, Jan 26, 2009 at 1:52 PM, William Tam <[email protected]> wrote: > On Mon, Jan 26, 2009 at 9:37 AM, Roman Kalukiewicz > <[email protected]> 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 <[email protected]>: >>> On Sat, Jan 24, 2009 at 9:08 PM, William Tam <[email protected]> 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/ >>> >> >
