8:58 a.m.
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
>>>
>>
>
--
- DML