2:54 p.m.
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.