[jboss-jira] [JBoss JIRA] (WFCORE-2270) Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361431#comment-13361431 ] 

Brian Stansberry commented on WFCORE-2270:
------------------------------------------

The work for this involves two PRs, the first of which is now merged:

1) Making whether a RuntimeCapability allows multiple registration points configurable via its Builder, and rejecting cases where multiple registration is attempted when not allowed.

2) Changing the default to not allow multiple registration.

A WildFly Core release will need to be done between 1) and 2) to allow uses in full to take advantage of the config option 1) provides.



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