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

[Tomasz Adamski]

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")(...)

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.