[jboss-jira] [JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs

[Paul Ferraro (JIRA)]

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

Paul Ferraro commented on WFLY-10339:
-------------------------------------

[~rsvoboda]
{quote}Will be old attributes deprecated and hidden in CLI for end user ?{quote}

The entire resource will be deprecated.  I don't know of any way to hide these from the CLI.  But this is a good point - I don't think the CLI sufficiently presents non-deprecated paths/attributes/operation as visually distinctive from non-deprecated paths/attributes/operations.  For example, if I use tab completion to suggest valid path elements, I am presented with possible paths for both deprecated and non-deprecated resources with no visual distinction.
I think this would be a very useful enhancement to the CLI, WDYT?

{quote}Is proposed change for the resources the only way to fix it or are there other ways ?{quote}

Even if galleon was not the original motivation behind this change, I would still strongly encourage the migration to multiple resources per broadcast/discovery group type.  The current strategy of using a single resource with optional alternate attributes will quickly break down as soon as we add a new broadcast/discovery type.  In fact, we will almost certainly introduce a new discovery group type that uses the discovery subsystem in the near future.

{quote}About the naming of the attributes, I prefer to have jgroups or socket as suffix and not as prefix.{quote}

While I can see the advantage of that - I can think of several counter-arguments:

* The introduction of a suffix-based naming scheme for resources providing the same capability would be inconsistent with the naming scheme already used by other subsystems.
* Users already have the ability to query possible endpoints that provide a given capability, thus they should never "be stuck a bit when finding proper resources" - especially if we document the change adequately.
* Basing a naming scheme based on legacy user behavior is not necessarily the most intuitive approach for new users

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