5:01 a.m.
On 1 Apr 2015, at 19:48, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
Are the classes in your 2) and 3) new base classes, or examples of what
users would need to do?
Given your question, I figure it's the latter.
Yes they are examples cut and
paste from a test case I am working on.
It seems like it would be fairly straightforward to add the 3) stuff to
AbstractAddStepHandler via a simple constructor param. The 1) stuff is
pretty simple too, but doing both it and 3) starts to get messy in terms
of too many constructor variants.
Rather than polluting the existing class too
much, since this should really be an uncommon case (?) perhaps we need an
AbstractOrderedAddStepHandler. But it is a bit weird since the parent and the child both
need to override this differently. It shouldn’t be too hard to come up with something
nicer though, I’ll let you know once I have had a play.
What about re-ordering? Done via add/remove?
Yes that would need to be done via
remove and add (with add-index). Moving stuff around would still need to trigger awareness
that something changed, but perhaps that could be done with a handler registered for these
parent resources. e.g. something along the lines of
/some=where:reorder-children(child-type=orderedA, order=[tree, bush, hedge]). For now I
see this as a nice to have enhancement which can happen in the future :-)
On 4/1/15 7:54 AM, Kabir Khan wrote:
> I am working on being able to order child resources, this is important for things
like jgroups where the protocol order matters. On top of the domain operations work I
inherited from Emanuel the order will get propagated through the domain. Currently for
jgroups the only way to adjust the protocol order is to remove all protocols and add them
again, and on the domain ops branch (before what I am outlining here) upon reconnect any
new protocols end up at the end of the slave’s list.
>
> The steps to make a child resource ordered are currently:
> 1) Make the ‘parent’ resource’s add handler call a different factory method:
> @Override
> protected Resource createResource(OperationContext context) {
> Resource resource = Resource.Factory.create(false, “orderedA”, “orderedB");
//Names of the child types where ordering matters
> context.addResource(PathAddress.EMPTY_ADDRESS, resource);
> return resource;
> }
>
> 2) In the ordered child resource definitions, override the new
getOrderedChildResource() operation to
> class OrderedChildResourceDefinition extends SimpleResourceDefinition {
> public OrderedChildResourceDefinition(PathElement element) {
> super(PathElement.pathElement(“orderedA", new
NonResolvingResourceDescriptionResolver(),
> new OrderedChildAddHandler(REQUEST_ATTRIBUTES), new
ModelOnlyRemoveStepHandler());
> }
>
> @Override
> protected boolean getOrderedChildResource() {
> return true;
> }
> ….
> }
> This has the effect of adding a parameter called ‘add-index’ to the ‘add’ operation’s
description. So if you have
> /some=where/orderedA=tree
> /some=where/orderedA=bush
> You can do e.g. /some=where/orderedA=hedge:add(add-index=1) and end up with:
> /some=where/orderedA=tree
> /some=where/orderedA=hedge
> /some=where/orderedA=bush
>
> 3) The final part is to adjust the ordered child resource’s add handler to honour the
add-index parameter:
>
> class OrderedChildAddHandler extends AbstractAddStepHandler {
> public OrderedChildAddHandler(AttributeDefinition... attributes) {
> super(attributes);
> }
>
> @Override
> protected Resource createResource(OperationContext context, ModelNode operation) {
> if (!operation.hasDefined(ADD_INDEX) || operation.get(ADD_INDEX).asInt() < 0) {
> return super.createResource(context);
> }
> return context.createResource(PathAddress.EMPTY_ADDRESS,
operation.get(ADD_INDEX).asInt());
> }
>
> 4) Not really related to what a user needs to do to create an ordered resource, but
1-3 are made possible by that on the resource interface I have two new methods:
> /**
> * Return the child types for which the order matters.
> *
> * @return {@code true} if the order of the children matters. If there are no
ordered
> * children and empty set is returned. This method should never return {@code
null}
> */
> Set<String> getOrderedChildTypes();
>
> /**
> * Register a child resource
> *
> * @param address the address
> * @param index the index at which to add the resource. Existing children with this
index and higher will be shifted one uo
> * @param resource the resource
> * @throws IllegalStateException for a duplicate entry or if the resource does not
support ordered children
> */
> void registerChild(PathElement address, int index, Resource resource);
>
>
> The main question I have is whether 1-3 are too ‘fragile’ and if we need something to
enforce/glue this together a bit more? At the same time ordered child resources should be
the exception rather than the rule.
>
>
>
> _______________________________________________
> 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