[wildfly-dev] Management Model: Squatter Resources

[David M. Lloyd]

Well, you can't really use "resource types" as part of the definition 
(i.e. justification) of what a resource type is, else nothing will ever 
meet that definition. :-)

But in any event, if it is important (and logical) to do so, I think we 
could easily extend operations to be "scoped" to an attribute group 
without really flexing the logical model very much.  The entire point of 
attribute groups is pretty much exactly what your use case is.

I don't want to marginalize your idea - it's a good idea - I just don't 
think I can accommodate it well in the new management model; if I did, 
it would end up being exactly like attribute groups anyway (but with 
distinct addresses).  But then making them be required would be impossible.

On 08/05/2014 09:15 AM, Heiko Braun wrote:
> But i guess attribute groups dont represent resource types. I.e they dont have operations associated, like types do.
>
> I think your example demonstrates a different concept.
>> Am 05.08.2014 um 15:49 schrieb "David M. Lloyd" <david.lloyd at redhat.com>:
>>
>>> On 08/05/2014 02:42 AM, Heiko Braun wrote:
>>> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>>>
>>> Background:
>>>
>>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>>>
>>> Problem:
>>>
>>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>>>
>>> /subsystem=datasources/data-source=ExampleDS
>>>
>>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>>>
>>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>>>
>>> /subsystem=ejb3/service=[async | remote | timer-service]
>>
>> We've solved this a different way in the "next" management model.  We
>> introduce the concept of an "attribute group".  In your example we'd
>> perhaps have an attribute group for async, one for remote, and one for
>> timer-service within the root resource.
>>
>> An attribute group is something like a composition resource.  They can
>> be optional or mandatory, and they can be named or anonymous.
>>
>> A named attribute group would be separately addressable as a unit, or
>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
>> Also they can be arbitrarily nested.
>>
>> An anonymous attribute group is just a logical grouping which is only
>> relevant to the server Java API itself and is invisible to the so-called
>> "DMR" or REST style API.  We can use these groups to retrofit existing
>> subsystems without breaking compatibility (this gives certain code reuse
>> benefits which are not important to this discussion).
>>
>> This way we preserve the invariant that all attributes with a given key
>> have a related type (we also introduce the concept of type hierarchies
>> though, which mitigates this constraint in a different way, but that's
>> not related to this).
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
- DML