Do the squatters have all the same attributes or does one still individually deal with them?

Am 05.08.2014 um 13:02 schrieb Heiko Braun <hbraun(a)redhat.com&gt;: > Not sure I understand the question. Can you elaborate on this? Will have service=async and service=timer-service have the same attributes / operations (as the type - the part left of the '=' - is the same)? I guess not, but would like to know anyway.

> > On 05 Aug 2014, at 12:59, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: > >> Do the squatters have all the same attributes or does one still individually deal with them? >

Am 05.08.2014 um 13:02 schrieb Heiko Braun <hbraun(a)redhat.com&gt;: > Not sure I understand the question. Can you elaborate on this? Will have service=async and service=timer-service have the same attributes / operations (as the type - the part left of the '=' - is the same)? I guess not, but would like to know anyway.

> > On 05 Aug 2014, at 12:59, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: > >> Do the squatters have all the same attributes or does one still individually deal with them? > -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Am 05.08.2014 um 13:45 schrieb Kabir Khan <kabir.khan(a)jboss.com&gt;: > I have used ‘specific’ vs ‘wildcard’ in the past when explaining/discussing stuff Aren't the "specific" ones also "singletons"; I think that would also capture the spirit.

Heiko _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: - how do we (programmatically) identify singleton resources? - how do we access their resource meta data (:read-resource-desciption)? The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/<key>=<value>/...) denotes the type. We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: /subsystem=messaging/hornetq-sever=*:read-children-types() { "outcome" => "success", "result" => [ ..., "ha-policy=live-only", "ha-policy=replicated-master", "ha-policy=replicated-slave", ... ] }

On 30 Oct 2014, at 11:40, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. > > In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). > > To represent this in the management model, I have added several resources under hornetq-server: > > /subsystem=messaging/ > hornetq-server=*/ > ha-policy=live-only > ha-policy=replicated-master > ha-policy=replicated-slave > ha-policy=replicated-colocated > ha-policy=shared-store-master > ha-policy=shared-store-slave > ha-policy=shared-store-colocated > > I have constraints for this ha-policy resource: > * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. > * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) > > Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. > > I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. > > I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. > > Heiko, is it something that would make sense for the console based on this resource description: > > [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) > { > "outcome" => "success", > "result" => [ > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-colocated") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-master") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-slave") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "live-only") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-master") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-slave") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-colocated") > ], > "outcome" => "success", > "result" => { > ... > } > } > ] > } > > jeff > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> On 31 Oct 2014, at 16:48, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > > On 10/30/14, 6:55 AM, Heiko Braun wrote: >> >> Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. >> >> The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: >> >> - how do we (programmatically) identify singleton resources? >> - how do we access their resource meta data (:read-resource-desciption)? >> >> The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/<key>=<value>/...) denotes the type. >> >> We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: >> >> /subsystem=messaging/hornetq-sever=*:read-children-types() >> { >> "outcome" => "success", >> "result" => [ >> ..., >> "ha-policy=live-only", >> "ha-policy=replicated-master", >> "ha-policy=replicated-slave", >> ... >> ] >> } >> > I haven't taken action on this specific request before because this > general area is a really broad topic and I wanted to let thinking play > out. But we've been thinking about it quite a while now and there's a > consensus that these singleton resource types exist and there's no > reason not to improve the API in this way. > > I opened https://issues.jboss.org/browse/WFCORE-208 and we'll be sure > it's resolved for the WF 9 Beta1. > > Please have a look at the description of that JIRA, where I'm quite > precise about the semantics. That looks very good (and precise!)

>> On 30 Oct 2014, at 11:40, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >> >>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>> >>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>> >>> To represent this in the management model, I have added several resources under hornetq-server: >>> >>> /subsystem=messaging/ >>> hornetq-server=*/ >>> ha-policy=live-only >>> ha-policy=replicated-master >>> ha-policy=replicated-slave >>> ha-policy=replicated-colocated >>> ha-policy=shared-store-master >>> ha-policy=shared-store-slave >>> ha-policy=shared-store-colocated >>> >>> I have constraints for this ha-policy resource: >>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>> >>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>> >>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>> >>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>> >>> Heiko, is it something that would make sense for the console based on this resource description: >>> >>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>> { >>> "outcome" => "success", >>> "result" => [ >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "live-only") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> } >>> ] >>> } >>> >>> jeff >>> >>> -- >>> Jeff Mesnil >>> JBoss, a division of Red Hat >>> http://jmesnil.net/ >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). To represent this in the management model, I have added several resources under hornetq-server: /subsystem=messaging/ hornetq-server=*/ ha-policy=live-only ha-policy=replicated-master ha-policy=replicated-slave ha-policy=replicated-colocated ha-policy=shared-store-master ha-policy=shared-store-slave ha-policy=shared-store-colocated I have constraints for this ha-policy resource: * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. Heiko, is it something that would make sense for the console based on this resource description: [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) { "outcome" => "success", "result" => [ { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "replication-colocated") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "replication-master") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "shared-store-slave") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "live-only") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "shared-store-master") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "replication-slave") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "shared-store-colocated") ], "outcome" => "success", "result" => { ... } } ] } jeff

On 30 Oct 2014, at 14:08, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: I mean, a single child where there can be many possible types for that child.

No, we don't. That currently would have to be handled in a custom way by the OSH that does the add for any of the children. There are some bits and pieces in the metadata that can help with doing some sort of automated validation (i.e. a currently basically unused max/min child count thing) but I don't think what's there is sufficient. The fact the metadata isn't there means a client like the console couldn't enforce the constraint server side, for a better UX.

On 10/30/14, 8:08 AM, David M. Lloyd wrote: > I mean, a single child where there can be many possible types for that > child. > > On 10/30/2014 08:01 AM, David M. Lloyd wrote: >> I think that polymorphism is a new use case for 'squatters'. I wonder >> if we have any existing code which enforces single children? >> >> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>> >>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>> >>> To represent this in the management model, I have added several resources under hornetq-server: >>> >>> /subsystem=messaging/ >>> hornetq-server=*/ >>> ha-policy=live-only >>> ha-policy=replicated-master >>> ha-policy=replicated-slave >>> ha-policy=replicated-colocated >>> ha-policy=shared-store-master >>> ha-policy=shared-store-slave >>> ha-policy=shared-store-colocated >>> >>> I have constraints for this ha-policy resource: >>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>> >>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>> >>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>> >>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>> >>> Heiko, is it something that would make sense for the console based on this resource description: >>> >>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>> { >>> "outcome" => "success", >>> "result" => [ >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "live-only") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> } >>> ] >>> } >>> >>> jeff >>> >> >

Using schema-ish things like min/max was probably a bad idea on my part. After trying to model XML schema in various ways for various reasons over the years, I know now that the simpler our rules are, the easier it will be to implement a cohesive and useful UX. IMO any currently unused and un-useful constructs like this that are hanging around probably need to be pruned, before someone actually uses them and makes everyone's live more difficult. :-) On 10/30/2014 08:44 AM, Brian Stansberry wrote: > No, we don't. That currently would have to be handled in a custom way by > the OSH that does the add for any of the children. > > There are some bits and pieces in the metadata that can help with doing > some sort of automated validation (i.e. a currently basically unused > max/min child count thing) but I don't think what's there is sufficient. > > The fact the metadata isn't there means a client like the console > couldn't enforce the constraint server side, for a better UX. > > On 10/30/14, 8:08 AM, David M. Lloyd wrote: >> I mean, a single child where there can be many possible types for that >> child. >> >> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >> > >

On Oct 30, 2014, at 9:12 AM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff’s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: /subsystem=messaging=*:read-resource-definition If the result contained nested N sets of resource definitions, as previously discussed, it’s all pretty straight forward. > On Oct 30, 2014, at 9:00 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > > I'm not so sure that bad idea was yours. > > But +1 on getting rid of the existing min/max thing. > > On 10/30/14, 8:58 AM, David M. Lloyd wrote: >> Using schema-ish things like min/max was probably a bad idea on my part. >> After trying to model XML schema in various ways for various reasons >> over the years, I know now that the simpler our rules are, the easier it >> will be to implement a cohesive and useful UX. >> >> IMO any currently unused and un-useful constructs like this that are >> hanging around probably need to be pruned, before someone actually uses >> them and makes everyone's live more difficult. :-) >> >> On 10/30/2014 08:44 AM, Brian Stansberry wrote: >>> No, we don't. That currently would have to be handled in a custom way by >>> the OSH that does the add for any of the children. >>> >>> There are some bits and pieces in the metadata that can help with doing >>> some sort of automated validation (i.e. a currently basically unused >>> max/min child count thing) but I don't think what's there is sufficient. >>> >>> The fact the metadata isn't there means a client like the console >>> couldn't enforce the constraint server side, for a better UX. >>> >>> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>>> I mean, a single child where there can be many possible types for that >>>> child. >>>> >>>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>>> if we have any existing code which enforces single children? >>>>> >>>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>>> >>>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>>> >>>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>>> >>>>>> /subsystem=messaging/ >>>>>> hornetq-server=*/ >>>>>> ha-policy=live-only >>>>>> ha-policy=replicated-master >>>>>> ha-policy=replicated-slave >>>>>> ha-policy=replicated-colocated >>>>>> ha-policy=shared-store-master >>>>>> ha-policy=shared-store-slave >>>>>> ha-policy=shared-store-colocated >>>>>> >>>>>> I have constraints for this ha-policy resource: >>>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>>> >>>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>>> >>>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>>> >>>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>>> >>>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>>> >>>>>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>>> { >>>>>> "outcome" => "success", >>>>>> "result" => [ >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "replication-colocated") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "replication-master") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "shared-store-slave") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "live-only") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "shared-store-master") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "replication-slave") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "shared-store-colocated") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> } >>>>>> ] >>>>>> } >>>>>> >>>>>> jeff >>>>>> >>>>> >>>> >>> >>> >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

On Oct 30, 2014, at 10:16 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: I shouldn't have mentioned min/max, as my only point was that it was a crusty thing out there that doesn't really address the problem. In this case, yes, there could be a 1:1 address to name relationship, but there is nothing in our metadata that describes that only one of those addresses can legally exist in a given tree. We have an "alternatives" description for the requirement for a choice amongst attributes, but nothing like that for resources. On 10/30/14, 9:15 AM, Jason Greene wrote: > Wow I am error-prone in the morning! > > "1:1 address to name relationship” > > -> 1:1 address to description relationship > > "/subsystem=messaging=*:read-resource-definition” > > -> subsystem=messaging=*:read-resource-description > >> On Oct 30, 2014, at 9:12 AM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: >> >> It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff’s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: >> >> /subsystem=messaging=*:read-resource-definition >> >> If the result contained nested N sets of resource definitions, as previously discussed, it’s all pretty straight forward. >> >> >>> On Oct 30, 2014, at 9:00 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >>> >>> I'm not so sure that bad idea was yours. >>> >>> But +1 on getting rid of the existing min/max thing. >>> >>> On 10/30/14, 8:58 AM, David M. Lloyd wrote: >>>> Using schema-ish things like min/max was probably a bad idea on my part. >>>> After trying to model XML schema in various ways for various reasons >>>> over the years, I know now that the simpler our rules are, the easier it >>>> will be to implement a cohesive and useful UX. >>>> >>>> IMO any currently unused and un-useful constructs like this that are >>>> hanging around probably need to be pruned, before someone actually uses >>>> them and makes everyone's live more difficult. :-) >>>> >>>> On 10/30/2014 08:44 AM, Brian Stansberry wrote: >>>>> No, we don't. That currently would have to be handled in a custom way by >>>>> the OSH that does the add for any of the children. >>>>> >>>>> There are some bits and pieces in the metadata that can help with doing >>>>> some sort of automated validation (i.e. a currently basically unused >>>>> max/min child count thing) but I don't think what's there is sufficient. >>>>> >>>>> The fact the metadata isn't there means a client like the console >>>>> couldn't enforce the constraint server side, for a better UX. >>>>> >>>>> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>>>>> I mean, a single child where there can be many possible types for that >>>>>> child. >>>>>> >>>>>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>>>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>>>>> if we have any existing code which enforces single children? >>>>>>> >>>>>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>>>>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>>>>> >>>>>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>>>>> >>>>>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>>>>> >>>>>>>> /subsystem=messaging/ >>>>>>>> hornetq-server=*/ >>>>>>>> ha-policy=live-only >>>>>>>> ha-policy=replicated-master >>>>>>>> ha-policy=replicated-slave >>>>>>>> ha-policy=replicated-colocated >>>>>>>> ha-policy=shared-store-master >>>>>>>> ha-policy=shared-store-slave >>>>>>>> ha-policy=shared-store-colocated >>>>>>>> >>>>>>>> I have constraints for this ha-policy resource: >>>>>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>>>>> >>>>>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>>>>> >>>>>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>>>>> >>>>>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>>>>> >>>>>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>>>>> >>>>>>>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>>>>> { >>>>>>>> "outcome" => "success", >>>>>>>> "result" => [ >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "replication-colocated") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "replication-master") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "shared-store-slave") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "live-only") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "shared-store-master") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "replication-slave") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "shared-store-colocated") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> } >>>>>>>> ] >>>>>>>> } >>>>>>>> >>>>>>>> jeff >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

Is it really polymorphism though if you do not share attributes or operations? It sounds like these are all distinct types just sharing the same portion of an address. The primary justification for this modeling approach seems to be: 1) Avoid the user having to assign a name 2) Enforce a single occurrence of a “type” > On Oct 30, 2014, at 8:01 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > > I think that polymorphism is a new use case for 'squatters'. I wonder > if we have any existing code which enforces single children? > > On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >> >> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >> >> To represent this in the management model, I have added several resources under hornetq-server: >> >> /subsystem=messaging/ >> hornetq-server=*/ >> ha-policy=live-only >> ha-policy=replicated-master >> ha-policy=replicated-slave >> ha-policy=replicated-colocated >> ha-policy=shared-store-master >> ha-policy=shared-store-slave >> ha-policy=shared-store-colocated >> >> I have constraints for this ha-policy resource: >> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >> >> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >> >> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >> >> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >> >> Heiko, is it something that would make sense for the console based on this resource description: >> >> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >> { >> "outcome" => "success", >> "result" => [ >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "live-only") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> } >> ] >> } >> >> jeff >> > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

On Oct 30, 2014, at 10:23 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: The main advantage of polymorphism (which is really just a way of saying "decoupling model location from node type") is (perhaps obviously) that you can use the same model location for more than one type. This means that user interface frameworks (for example) could know that there is only one possible sub-resource address, say "service=ha-policy" (to use Heiko's original naming example mixed with Jeff's practical example). Then it only has to make a decision as to how to render the resource, rather than having to analyze the model to know that, of the six possible children for "ha-policy", only one can ever be present. On 10/30/2014 09:06 AM, Jason Greene wrote: > Is it really polymorphism though if you do not share attributes or operations? > > It sounds like these are all distinct types just sharing the same portion of an address. > > The primary justification for this modeling approach seems to be: > > 1) Avoid the user having to assign a name > 2) Enforce a single occurrence of a “type” > > >> On Oct 30, 2014, at 8:01 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >> >> I think that polymorphism is a new use case for 'squatters'. I wonder >> if we have any existing code which enforces single children? >> >> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>> >>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>> >>> To represent this in the management model, I have added several resources under hornetq-server: >>> >>> /subsystem=messaging/ >>> hornetq-server=*/ >>> ha-policy=live-only >>> ha-policy=replicated-master >>> ha-policy=replicated-slave >>> ha-policy=replicated-colocated >>> ha-policy=shared-store-master >>> ha-policy=shared-store-slave >>> ha-policy=shared-store-colocated >>> >>> I have constraints for this ha-policy resource: >>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>> >>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>> >>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>> >>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>> >>> Heiko, is it something that would make sense for the console based on this resource description: >>> >>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>> { >>> "outcome" => "success", >>> "result" => [ >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "live-only") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> } >>> ] >>> } >>> >>> jeff >>> >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

There's a separate branch of this thread that looks to be getting into discussing use cases for polymorphism, so here I'll focus on details a bit. Right now our types are tied to addresses. The address defines the type, and is used to find the description of the type. This is even true with complex attributes, just with a slightly different mechanism. To get away from having the address define the type, we would need some other mechanism for declaring a type. In a hangout today, we brainstormed about using special attributes[1] in any complex ModelNode (i.e. any resource or a complex attribute of OBJECT type). We'd need some clear mechanism for resolving type definitions based on the data in those special attributes. The description of the parent would have to declare what the valid types are, in some combination with what the valid addresses are. That would allow tooling like the console to guide the user when creating new items or radically changing existing ones. For something like the CLI it gets more cumbersome, as our UX (which I like a lot) is based on tab completion. Tab completion could still suggest a type, but the user's choice would no longer get recorded in the current input. This is quite a bit more flexible than the current approach, but also a fair bit more cumbersome for the many cases where there's no need for polymorphism, so the use case discussion is important. [1] We discussed using ".xxx" e.g. ".type" and ".namespace", with attributes whose names begin with the "." prefix becoming reserved. The '.' is kind of nice because it's intuitively like a hidden file on a filesystem, and if we use dot syntax to separate between levels in a complex attribute or between an attribute group and an item, this case fits in. > This means that user interface frameworks (for example) could know that > there is only one possible sub-resource address, say "service=ha-policy" > (to use Heiko's original naming example mixed with Jeff's practical > example). Then it only has to make a decision as to how to render the > resource, rather than having to analyze the model to know that, of the > six possible children for "ha-policy", only one can ever be present. > > On 10/30/2014 09:06 AM, Jason Greene wrote: >> Is it really polymorphism though if you do not share attributes or operations? >> >> It sounds like these are all distinct types just sharing the same portion of an address. >> >> The primary justification for this modeling approach seems to be: >> >> 1) Avoid the user having to assign a name >> 2) Enforce a single occurrence of a “type” >> >> >>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >>> >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone@localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > --

Is it really polymorphism though if you do not share attributes or operations? It sounds like these are all distinct types just sharing the same portion of an address. The primary justification for this modeling approach seems to be: 1) Avoid the user having to assign a name 2) Enforce a single occurrence of a “type”

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

On 08/05/2014 09:00 AM, Brian Stansberry wrote: > On 8/5/14, 8:49 AM, David M. Lloyd wrote: >> 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). >> > > Is there a notion of null/undefined for the attribute group itself, as > opposed to the individual attributes? Yes, but only for "optional" attribute groups. IOW the resource author can decide if that's appropriate or not. I have not yet completely worked out how manipulation operations would look for this. I think it may be closely tied in to what we do for so-called "complex" attributes though. > That's a conceptual distinction -- a resource doesn't exist unless it's > added. Yes, it's a distinct concept. However (at least for the given example) I think that an attribute group is a better fit. The problem with "squatters" is that they don't really have a common API, and yet they aren't really independent - it's just a way of addressing the composition of a parent resource.

You can't really use the mechanism (as described) to plug in extensions. So it's yet another logical model for resources we have to introduce. I think in terms of the logical model of management resources themselves, we're close to the breaking point in a couple ways, even if only due to the way we handle subsystems, inter-resource linkage etc., where it's going to be difficult to come up with any kind of internally consistent management API unification concept if we make it any more complex. The problem that Heiko is trying to solve, I think, is that there's a tension here. Large resources aren't, by themselves, inherently "bad", in terms of the system and its implementation. However once you introduce human interfaces like CLI and console, it becomes difficult for people to manage due to just the overall spamming of management information. So there's a tension between having complete and robust resources, and making them consumable by normal human beings. I definitely agree with this, and I think that trying to solve this is a very reasonable and logical step (and those who know me should know that "reasonable" is about the highest compliment that I give). But if we do solve this then it has to be done in a way that we can adapt to, or else we may cross the line from "the new management is a pretty big effort" to "the new management model is dead". And I think that if the new management model can't accommodate a new abstraction in a logically consistent way, then nothing else will be able to either.

Am 05.08.2014 um 15:49 schrieb "David M. Lloyd" <david.lloyd(a)redhat.com&gt;: > 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.

Am 05.08.2014 um 15:49 schrieb David M. Lloyd <david.lloyd(a)redhat.com&gt;: > > 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. The latter scares me, as its representation in UIs can become quite problematic.