[jboss-jira] [JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs
[
https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin...
]
Paul Ferraro commented on WFLY-10339:
-------------------------------------
[~ehugonnet] {quote}Isn't the use of capabilities be sufficient to fix this without
creating new resources in the model ?{quote}
As I mentioned above, we already use capability references for the jgroups vs multicast
attributes. The issue is that the requirements for the resource are determined by whether
or not the jgroups-cluster attribute is defined. I had to make a similar change for the
singleton subsystem, where the requirements for the resource were determined by whether or
not the "cache" attribute was defined (remember the whole
DefaultableCapabilityReference stuff?)
Broadcast/discovery-group resources have ambiguous requirement specs
--------------------------------------------------------------------
Key: WFLY-10339
URL: https://issues.jboss.org/browse/WFLY-10339
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 12.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, the broadcast/discovery-group resources have messy requirement specs, as the
capabilities that they require are dependent whether or not the jgroups-cluster attribute
is defined.
I suggest splitting these resources into 2:
{code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
{code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
which requires clustering capabilities
and
{code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
{code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
which requires a socket-binding capability.
This results in clearer requirement specs - which helps simplify the introspection of
this subsystem for provisioning purposes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)