Bug 973086 – Component properties does not work when more than one Camel implementation is present

Bug 973086 - Component properties does not work when more than one Camel implementation is present

Summary:	Component properties does not work when more than one Camel implementation is...

Status:	ASSIGNED

Aliases:	None

Product:	JBoss Fuse Service Works 6
Classification:	JBoss
Component:	SwitchYard (Show other bugs)
Sub Component:
Version:	6.0.0
Hardware:	Unspecified Unspecified

Priority	unspecified Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	kconner
QA Contact:	Matej Melko
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2013-06-11 05:20 EDT by Jiri Pechanec
Modified:	2018-03-29 17:51 EDT (History)
CC List:	7 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:	If you activate a Camel component, it sets the component properties. If there is more than one Camel implementation, the component properties set for each Camel component effectively overrides the previous setting.
Story Points:	---
Clone Of:
Environment:
Last Closed:
Type:	Bug
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
JBoss Issue Tracker	SWITCHYARD-2144	Critical	Resolved	SwitchYardPropertiesParser does not work for multiple Components	2015-04-13 16:28:41 EDT

Groups: None (edit)

Description Jiri Pechanec 2013-06-11 05:20:01 EDT

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.

Comment 1 Rob Cernich 2014-10-21 14:34:40 EDT

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?

Comment 2 JBoss JIRA Server 2014-12-15 12:41:02 EST

Rob Cernich <rcernich@redhat.com> updated the status of jira SWITCHYARD-2144 to Resolved

Comment 3 Rob Cernich 2014-12-15 12:42:25 EST

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).

Comment 4 Len DiMaggio 2015-02-17 12:36:32 EST

Nacking this bugzilla - this is an EAP issue and FSW 6.2 will not embed EAP.

Comment 5 Ken Johnson 2015-03-12 14:26:06 EDT

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.

Comment 6 tcunning 2015-04-01 11:38:43 EDT

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).

Note You need to log in before you can comment on or make changes to this bug.