[wildfly-dev] Management Model: Squatter Resources
David M. Lloyd
david.lloyd at redhat.com
Thu Oct 30 11:33:58 EDT 2014
At least that's the advantage for this particular use case. Another
advantage that I feel I cannot possibly overstate is, it elegantly
solves our Elytron authentication client configuration problem without
requiring resource sequences. We can have a list of attribute
polymorphic groups instead.
On 10/30/2014 10:23 AM, David M. Lloyd 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 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
>>
>
--
- DML
More information about the wildfly-dev
mailing list