[wildfly-dev] Management model attribute groups - example fixed

[Brian Stansberry]

On 2/4/15 1:51 PM, Tomasz Adamski wrote:
> Sent once again because of broken examples in previous mail:
>
> I would like to raise once again the issue of nested attribute groups.
>
> I started rewriting iiop subsystem so that it uses attribute groups and I think that in many cases it would be covenient and more descriptive if we are able to nest attribute groups.
>
> There are two models related to it: subsystem xml description and management api but I believe that both of them may benefit from nested attributes.
>
> Example:
>
> Currently ior-settings xml tag is used to group all ior releted configuration:
> <ior-settings>
>      <as-context integrity="required" (...)/>
>      <sas-context auth-method="username_password" (...)/>
>      <transport-config caller-propagation="supported" (...)/>
> </ior-settings>
>
> After attribute group refactor it would currently turn to:
> <as-context integrity="required" (...)/>
> <sas-context auth-method="username_password" (...)/>
> <transport-config caller-propagation="supported" (...)/>
>
> It would be nice to be able to group them together once again. This may be achieved by adding methods to PersistentResourceXMLDescription which will make it possible to create more complex xml schema independent of attribute groups. On the other hand, what is beneficial from xml point of view may also be beneficial for management tools: if those three elements have all different groups there they could be displayed separately after sort but if we created a nested groups and do a nested sorting of them then they could be grouped together in management tools too. Moreover, all information about attribute will still be containted in its definition and  subsystem creation using PersistentResourceXMLDescription will stay as simple as it is now.
>
> Having that in mind I would suggest extending the group notion from flat to nested and create direct mapping between group parts and xml tags.
>
> In the above example we would have:
>
> AttributeDefinition INTEGRITY = (...).setAttributeGroup("ior-settings.as-context")(...)
> AttributeDefinition AUTH_METHOD = (...).setAttributeGroup("ior-settings.sas-context")(...)
> AttributeDefinition CALLER_PROPAGATION = (...).setAttributeGroup("ior-settings.transport-config")(...)
>

I think this information would be better reflected in the attribute 
description metadata as a list of string instead of a string with dot 
syntax. If dot syntax is used in the metadata, a management client needs 
to understand how to parse that information, versus having it be more 
obvious.

The AttributeDefinition builder syntax can still be easy by using 
setAttributeGroup(String... group)

> PersistentResourceXMLDescription xmlDescription = builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)
>
> This would create parser able of parsing:
>
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
>      (...)
>      <ior-settings>
>          <as-context integrity="required" (...)/>
>          <sas-context auth-method="username_password" (...)/>
>          <transport-config caller-propagation="supported" (...)/>
>      </ior-settings>
>      (...)
> </subsystem>
>
>
> Problems:
> How to represent the group in management api?
>
> LIST vs STRING
> :read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
> :read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])
>
> String seem more convenient but there are some consequences of keeping a LIST (which attribute group actually is) in the form of the STRING: some parts of management client code will have to do additional work because of that (f.e. string parsing), tab completion feature will have to hint string part by part which may be not consistent with other parts of api etc.
>

The attribute description metadata can be in the form of a LIST without 
requiring that the parameter to read-attribute-group be a LIST. It's an 
inconsistency if they are not, which isn't ideal. But for the simple 
case, having to do group=[foo] would be bad.

>
>
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat