4:46 p.m.
So the key thing I missed was modeling exclusivity has to apply to the collection
of possible types. This could be a polymorphic relationship or just a substitution
group like notion (similar to ALTERNATIVES).
When you say “same model location for more than one type”, do you mean multiple types
for a fully qualified address (e.g. datasource=awesomeness can have say 3 possible types)?
If so I think the complexity goes up quite a bit since you need that additional type
specifier. I would like to better understand use-cases where that would becomes
important.
On Oct 30, 2014, at 10:23 AM, David M. Lloyd
<david.lloyd(a)redhat.com> 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>
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
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat