[wildfly-dev] Management Model: Squatter Resources

[Jason Greene]

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 at redhat.com> 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 at 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 at 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