SwitchYard uses internally one CamelContext. When a Camel component is activated in org/switchyard/component/camel/deploy/CamelActivator it sets PropertiesParser for Camel Properties Component. The problem is that this setting is global for the single shared CamelContext. So if there are two or more Camel implementations, then the PropertiesParser is set for each of them effectively overriding previous setting. This ensures that Camel implementations shares properties from the last Camel implementation that was activated.
Hey Kevin, I don't think we can address this issue in the code. At best, we should document that names of properties specified for camel components must be unique throughout the application. WDYT?
Rob Cernich <rcernich> updated the status of jira SWITCHYARD-2144 to Resolved
I'm n'ack'ing this as we cannot isolate Camel's property resolver to specific components (i.e. we either can't or don't know how to fix this).
Nacking this bugzilla - this is an EAP issue and FSW 6.2 will not embed EAP.
Does this change with the camel-wildfly subsystem? Will SwitchYard 2 on EAP 6.4 use camel-wildfly modules? If this bug is unaffected by camel-wildfly, I will nack for now.
This should not be affected by camel-wildfly. In the SwitchYard ER2 submission, we will be reusing the camel-wildfly modules (commit is already in).
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.