I have a simple drools service in SY specifying some channel. <rules:channels> <rules:channel class="org.switchyard.component.common.knowledge.service.SwitchYardServiceChannel" name="heartChannel" operation="heartBeat" reference="RulesComponent/AuditorCEPService"/> </rules:channels> Formerly it was sufficient to specify just the reference name in the reference attribute. Not it must contain the component name as well. The rules component name is RulesComponent and the service reference is properly defined. I would expect it to specify just the reference name. Including the full switchyard.xml.
Created attachment 789602 [details] Switchyard config
Agree that the component name should not be required here. I might have missed this in the core refactoring that requires reference names to be qualified with component name. The code for rules should be the same as for bpm in terms of converting a reference name used in a service task to the qualified name that the bus expects. I thought I changed this for rules as well, but maybe no ...
The thing is that the references are stored in the registry with component name, which is IMHO wrong, because the references registry is component specific, isn't it?
Users should not care about how references are represented in the internal registry. That said, references are qualified by component name because a reference name (e.g. "MyService") can be used across components and each reference is unique to the component. So you could have: component1/MyService component2/MyService The contract and policies for each component can be different.
I should have added that the reference registry is not component-specific. There is one registry and that's why the local reference name used in a component is qualified by the component name in the registry. Again, users should never have to understand or account for this in their applications - it's an internal implementation detail.
It is clear that the registry is internal. I just wanted to provide some information I thought I discovered. I saw multiple instances of DomainImpl in memory during debugging. This is why I believed there are more registries. Obviously I was wrong so sorry for confusion.
No worries. :-) It's actually a big change in SOA 6 that the registry is private, since the registry contents were very visible in SOA 5. I wanted to give you a bit of background on the internals so that if you see this leaking into applications at all (as with this BZ), please flag it as an issue.
David Ward <dward> made a comment on jira SWITCHYARD-1691 https://github.com/jboss-switchyard/components/pull/563 Tested app with service references both WITH and withOUT the component name in the channel reference.
Keith Babo <kbabo> made a comment on jira SWITCHYARD-1691 pushed
Verified in ER7
Keith Babo <kbabo> updated the status of jira SWITCHYARD-1691 to Closed