[ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10339: ------------------------------------- [~jmesnil] {quote}Capabilities and requirements based on attributes should be sufficient: * if socket-binding is defined, it requires a socket-binding capability * if jgroups-xxx attribute is defined, it requires a JGroups capability etc. {quote} I don't think this accurately describes the complexity of the feature requirement specs for this resource. Rather, the current feature specification logic is: * When the jgroups-cluster attribute is defined: ** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value. ** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name. * Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute. AIUI, the complexity for provisioning is two-fold: # The attribute that toggles whether a JGroups supplied capability is needed is not the same attribute that supplies the name of the requirement # When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined. We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined. However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding. -- This message was sent by Atlassian JIRA (v7.5.0#75005)