[wildfly-dev] Management Model: Squatter Resources

[Tomaž Cerar]

Hi,

when I first started reading I was bit alarmed you want to do something
crazy thing :-)

Given that you just want to add extra option to read-children-types
operation i see no harm in that.
I would just name them differently, in all our terminology this types are
just non wildcard resources
if you look at the PathElement which is essentially what you are talking
about.
in case that you have path element key = * you have wildcard
address/resource which you use as normal
for cases were you have key=value you have static non wildcard
address/resource.

so i would rather use some term in this vicinity.

--
tomaz



On Tue, Aug 5, 2014 at 9:42 AM, Heiko Braun <hbraun at redhat.com> 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]
>
> In this case each resource under /subsystem=ejb3/service has a different
> type and only a single instance can exist:
>
> /service=async
> /service=remote
> /service=timer-service
>
> Lacking a better alternative, I coined the term 'squatter' resources,
> because these resources squat a specific address slots. Squatter resources
> can be pre-registered or non-exisiting when the management layer is started.
>
> In order to provide a data binding layer for the management console, we
> need to access the definition of a resource (:read-resource-description).
> With squatter resources this is basically impossible, because the existence
> of these types is hidden in the general API. I.e. sticking to the previous
> example, when querying the resource definition for the ejb3 subsystem, it
> pretends only single type 'service' exists, although it's actually three
> different 'service' types
>
> ./subsystem=ejb3:read-children-types
> {
>    "outcome" => "success",
>    "result" => [
>        [...],
>        "service",
>        [...]
>    ]
> }
>
> Proposal:
>
> After a chat with Brian yesterday, we are proposing a new request
> parameter to the :read-children-types operations, that augments the result
> to reveal the existence of squatter resources:
>
> ./subsystem=ejb3:read-children-types(include-squatters=true)
> {
>    "outcome" => "success",
>    "result" => [
>        [...],
>        "service=async",
>         "service=remote",
>         "service=timer-service"
>        [...]
>    ]
> }
>
> This works in a backwards compatible way and allows us to identify
> squatter resources and get to their resource definition.
>
>
> Thoughts and comments welcome.
> If you can think of better term than 'squatter' resources, please let me
> know as well.
>
> Regards, Heiko
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140805/110c4a57/attachment.html