[wildfly-dev] Ordered child resources

[Kabir Khan]

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.