[
https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugi...
]
Brian Stansberry updated WFCORE-2270:
-------------------------------------
Description:
CapabilityRegistry.registerCapability is allowing more than one registration point for the
same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible*
capability can be registered from more than one location, and the user then chooses to
configure one. And the same capability name can be configured at more than one address in
a domain-wide config, so long as those addresses have different scopes. But within the
same scope, usually the config can only have the same cap in one place.
There are exceptions to this rule though, so allowing more than one registration point
needs to be configurable. Exceptions are basically cases where different resources can
register the capability, and the authors of those know about this and have coded up the
capability implementations to check for duplication and correctly deal it. For example:
1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check
for the presence of jgroups before putting in it's impl. Both are owned by the same
author (WildFly clustering team.)
2) On an HC, interfaces and paths can be registered in multiple locations that all end up
with the same scope. But they don't have to be. The impl understands the precedence
rules between those possible locations and the actual capability reflects the correct
config.
I think this latter case is why CapabilityRegistry.registerCapability still allows
multiple registration points. But it's a corner case that shouldn't drive all
behavior.
was:CapabilityRegistry.registerCapability is allowing more than one registration point
for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability
can be registered from more than one location, and the user then chooses to configure one.
An the same capability name can be configured at more than one address in a domain-wide
config, so long as those addresses have different scopes. But within the same scope, the
config can only have the same cap in one place.
Capability registry should not allow more than one registration point
for a RuntimeCapabilityRegistration
---------------------------------------------------------------------------------------------------------
Key: WFCORE-2270
URL:
https://issues.jboss.org/browse/WFCORE-2270
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
CapabilityRegistry.registerCapability is allowing more than one registration point for
the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible*
capability can be registered from more than one location, and the user then chooses to
configure one. And the same capability name can be configured at more than one address in
a domain-wide config, so long as those addresses have different scopes. But within the
same scope, usually the config can only have the same cap in one place.
There are exceptions to this rule though, so allowing more than one registration point
needs to be configurable. Exceptions are basically cases where different resources can
register the capability, and the authors of those know about this and have coded up the
capability implementations to check for duplication and correctly deal it. For example:
1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to
check for the presence of jgroups before putting in it's impl. Both are owned by the
same author (WildFly clustering team.)
2) On an HC, interfaces and paths can be registered in multiple locations that all end up
with the same scope. But they don't have to be. The impl understands the precedence
rules between those possible locations and the actual capability reflects the correct
config.
I think this latter case is why CapabilityRegistry.registerCapability still allows
multiple registration points. But it's a corner case that shouldn't drive all
behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)