[wildfly-dev] Ordered child resources

[Brian Stansberry]

On 4/2/15 11:53 AM, Kabir Khan wrote:
>
>> On 2 Apr 2015, at 17:17, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> On 4/2/15 6:11 AM, Kabir Khan wrote:
>>>
>>>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>>
>>>>
>>>>> On 1 Apr 2015, at 19:48, Brian Stansberry <brian.stansberry at 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.
>>> It is doable, but all the constructors are getting a bit messy anyway. I’ll add a builder to AbstractAddStepHandler instead.
>>
>> This (meaning the general problem, not a builder approach per se) can get complicated, due to the different varieties:
>>
>> AbstractBoottimeAddStepHandler
>> RestartParentResourceAddHandler
>>
>> The latter sounds particularly relevant for the child resources, as the need for ordering implies that it's the parent that's using the child's config data to manage some service.
> I have scrapped the builder approach for now since these classes are built for overriding. I have:
>
> public abstract class AbstractOrderedResourceAddStepHandler extends AbstractAddStepHandler {
>      //Constructors
>     ….
>
>      /**
>       * If this ia a parent resource with ordered child resources, return a set of the names of the ordered child types.
>       * If there are no ordered child types, return an empty set.
>       *
>       *  @return the ordered child types
>       */
>      protected Set<String> getOrderedChildTypes() {
>          return Collections.emptySet();
>      }
>
>      /**
>       * Return {@code true} if this is a child resource of a type whose parent supports ordered inserts
>       *
>       * @return whether ordered inserts are supportered
>       */
>      protected boolean supportIndexedAdd() {
>          return false;
>      }
>
>      @Override
>      protected Resource createResource(OperationContext context, ModelNode operation) {
>          Set<String> orderedChildTypes = getOrderedChildTypes();
> 	//Creates a parent with ordered children (if set is not empty)
>          Resource resource = Resource.Factory.create(false, orderedChildTypes);
>
> 	//Attempts to do the insert
>          int index = -1;
>          if (supportIndexedAdd() && operation.hasDefined(ADD_INDEX)) {
>              index = operation.get(ADD_INDEX).asInt();
>          }
>          if (index >= 0) {
>              context.addResource(PathAddress.EMPTY_ADDRESS, operation.get(ADD_INDEX).asInt(), resource);
>          } else {
>              context.addResource(PathAddress.EMPTY_ADDRESS, resource);
>          }
>          return resource;
>      }
> }
>
> but that does not take the restart part into account at all. Perhaps I should push this all up into AbstractAddHandler anyway. Do you mind having something like a
> public class AbstractAddHandler implements OperationStepHandler {
> ….
> 	protected ResourceCreator getResourceCreator() {
> 		return DEFAULT; // does what AbstractAddHandler does presently
> 	}
>
> 	protected Resource createResource(OperationContext context, ModelNode operation) {
> 		return getResourceCreator().createResource(context, operation);
> 	}
> }
>
> I could then have an implementation along the lines of
> public class OrderedResourceCreator implements ResourceCreator {
> 	private final Set<String> orderedChildTypes;
> 	private final boolean indexedAdd;
> 	public OrderedResourceCreator(Set<String> orderedChildTypes, boolean indexedAdd) {
> 		this.orderedChildTypes = orderedChildTypes;
> 		this.indexedAdd = indexedAdd;
>          }
> 	protected Resource createResource(OperationContext context, ModelNode operation) {
> 		//same as AbstractOrderedResourceAddStepHandler.createResource() above
> 	}
> }
> and have sub-classes override getResourceCreator() to return that. Or do you really, really want this in the constructor rather than in an overridden getter?
>

Overriding is ok. I forgot about all the AbstractAddStepHandler 
constructor variants that came with the capabilities/requirements work. 
Adding this means too many permutations. Maybe we can make those go away 
and revisit this, but I think what you propose is fine.


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