[wildfly-dev] Ordered child resources

[Brian Stansberry]

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.

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.

What about re-ordering? Done via add/remove?

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat