camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roman Kalukiewicz (JIRA)" <j...@apache.org>
Subject [jira] Work started: (CAMEL-343) Inconsistent exchange properties propagation
Date Wed, 27 Feb 2008 00:44:17 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Work on CAMEL-343 started by Roman Kalukiewicz.

> Inconsistent exchange properties propagation
> --------------------------------------------
>
>                 Key: CAMEL-343
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-343
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-core
>            Reporter: Roman Kalukiewicz
>            Assignee: Roman Kalukiewicz
>
> There is an inconsistency in exchange properties propagation. To show few examples:
> ||code||{{test}} property value at {{mock:test}} || due to ||
> |{code}
> from("direct:start")
>     .setProperty("test", "inStart")
>     .to("direct:subflow")
>     .to("mock:test");
> from("direct:subflow")
>     .setBody("test")
>     .setProperty("test", "inSubflow");
> {code} | inStart | properties are not propagated \\ back if they were set in super flow
|
> |{code}
> from("direct:start")
>     .setProperty("test", "inStart")
>     .to("direct:subflow")
>     .to("mock:test");
> from("direct:subflow")
>     .setProperty("test", "inSubflow")
>     .setBody("test");
> {code} | inSubflow | property is set to new value as \\ pipeline sends original \\ exchange
to first step of pipeline |
> |{code}
> from("direct:start")
>     .to("direct:subflow")
>     .to("mock:test");
> from("direct:subflow")
>     .setBody("test")
>     .setProperty("test", "inSubflow");
> {code} | inSubflow | properties are propagated \\ back by default |
> I believe we should clearly define how properties should be propagated:
> * should they be kept for the whole flow and every change is visible to sub/super flows,
or
> * should they be visible only in scope of *current* flow and interaction with sub-flows
(invoked by and endpoint) should be done with headers.
> I believe that first is easier for users as they have a way to hold some data for further
processing (while they are not exposed as protocol specific headers).
> If you have another ideas - please advice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message