-Original Message-
> From: Andi Abes [mailto:aa...@progress.com]
> Sent: Friday, January 30, 2009 2:17 PM
> To: dev@camel.apache.org
> Subject: RE: Components setting data on OUT
>
> Took a while, and Roman I think you made great points.
>
> I think that throughout t
AM
> To: dev@camel.apache.org
> Subject: Re: Components setting data on OUT
>
> 2009/1/27 Andi Abes :
> > Having finally caught up with the discussion about header/property
> > copying and propagation, I thought it might be interesting to circle
> > back to the origin
On Tue, Jan 27, 2009 at 1:23 AM, Claus Ibsen wrote:
> On Tue, Jan 27, 2009 at 6:02 AM, William Tam wrote:
>> On Mon, Jan 26, 2009 at 11:34 PM, Hadrian Zbarcea wrote:
>>> I think having dots ('.') in property names is not a good idea as they don't
>>> get along iirc with some technologies.
>>>
>>
2009/1/27 Andi Abes :
> Having finally caught up with the discussion about header/property
> copying and propagation, I thought it might be interesting to circle
> back to the original question Claus posed (slightly reworded) - what is
> the purpose of the out message?
>
> As a "flame generator" qu
of the exchange
- a readonly primordial input message, as provided by the user.
(start the flame...)
> -Original Message-
> From: Claus Ibsen [mailto:claus.ib...@gmail.com]
> Sent: Tuesday, January 27, 2009 1:23 AM
> To: dev@camel.apache.org
> Subject: Re: Components setti
On Tue, Jan 27, 2009 at 6:02 AM, William Tam wrote:
> On Mon, Jan 26, 2009 at 11:34 PM, Hadrian Zbarcea wrote:
>> I think having dots ('.') in property names is not a good idea as they don't
>> get along iirc with some technologies.
>>
>
> Sorry one more thing, the property name is just key to ex
On Mon, Jan 26, 2009 at 11:34 PM, Hadrian Zbarcea wrote:
> I think having dots ('.') in property names is not a good idea as they don't
> get along iirc with some technologies.
>
Sorry one more thing, the property name is just key to exchange
property map. I believe we already use dots in exchan
On Mon, Jan 26, 2009 at 11:34 PM, Hadrian Zbarcea wrote:
> I think having dots ('.') in property names is not a good idea as they don't
> get along iirc with some technologies.
>
I'm not worry about syntax right now.
> Secondly, my point was that at this time, I am against the idea of
> separati
I think having dots ('.') in property names is not a good idea as they
don't get along iirc with some technologies.
Secondly, my point was that at this time, I am against the idea of
separating the headers into two maps. I don't see a compelling reason
to do so and we should properly use p
On Mon, Jan 26, 2009 at 5:34 PM, Hadrian Zbarcea wrote:
>
> On Jan 26, 2009, at 4:17 PM, William Tam wrote:
>
>> On Mon, Jan 26, 2009 at 1:37 PM, Hadrian Zbarcea
>> wrote:
>>>
>>> I don't disagree, I was just suggesting that they should then travel as
>>> properties.
>>
>> Why shouldn't they (pro
On Jan 26, 2009, at 4:17 PM, William Tam wrote:
On Mon, Jan 26, 2009 at 1:37 PM, Hadrian Zbarcea
wrote:
I don't disagree, I was just suggesting that they should then
travel as
properties.
Why shouldn't they (protocol headers) travel as headers (to avoids
unnecessary copying between excha
On Mon, Jan 26, 2009 at 1:37 PM, Hadrian Zbarcea wrote:
> I don't disagree, I was just suggesting that they should then travel as
> properties.
Why shouldn't they (protocol headers) travel as headers (to avoids
unnecessary copying between exchange properties and protocol headers)?
> Whatever we
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 clas
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
On Mon, Jan 26, 2009 at 9:37 AM, 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 throug
I don't disagree, I was just suggesting that they should then travel
as properties. Whatever we name them, and whatever mechanism we
decide to use, as pointed out before, we need to distinguish between
headers that are endpoint/protocol specific and have no semantics
outside the endpoint a
On Mon, Jan 26, 2009 at 10:35 AM, Hadrian Zbarcea wrote:
> Hi,
>
> This headers business is a bit of a tricky one. I hit it last year in the
> context of security.
>
> I agree with the view that headers should only exist in the context of an
> endpoint. I think outside of that there is no guaran
Hi,
This headers business is a bit of a tricky one. I hit it last year in
the context of security.
I agree with the view that headers should only exist in the context of
an endpoint. I think outside of that there is no guarantee that the
semantics of a header is preserved. I am not sur
2009/1/26 Claus Ibsen :
> 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
>
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 throug
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 i
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
>
> 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 other
On Fri, Jan 23, 2009 at 4:45 PM, William Tam wrote:
> On Fri, Jan 23, 2009 at 2:33 AM, Willem Jiang wrote:
>> Hi Claus
>>
>> I agree the component should take responsible of copy the In message
>> headers into Out message headers. we could provides util class to do
>> that copy thing in camel-cor
On Fri, Jan 23, 2009 at 2:33 AM, Willem Jiang wrote:
> Hi Claus
>
> I agree the component should take responsible of copy the In message
> headers into Out message headers. we could provides util class to do
> that copy thing in camel-core.
> But the component should also need to make sure some of
On Fri, Jan 23, 2009 at 12:55 AM, Claus Ibsen wrote:
> Hi
>
> The OUT message really starts to irritate me.
>
> We have various components that set data on the OUT body and then the
> Pipeline will use this result as IN for then next node.
> What happens is then whatever headers etc from IN is los
On Fri, Jan 23, 2009 at 8:33 AM, Willem Jiang wrote:
> Hi Claus
>
> I agree the component should take responsible of copy the In message
> headers into Out message headers. we could provides util class to do
> that copy thing in camel-core.
> But the component should also need to make sure some of
Hi Claus
I agree the component should take responsible of copy the In message
headers into Out message headers. we could provides util class to do
that copy thing in camel-core.
But the component should also need to make sure some of the out message
header value which is copied from in message sho
28 matches
Mail list logo
