7:54 a.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.
1:48 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
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
6:11 a.m.
On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan(a)jboss.com>
wrote:
> 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.
It is doable, but all the constructors are getting a bit messy anyway. I’ll add a
builder to AbstractAddStepHandler instead.
>
> 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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:17 a.m.
On 4/2/15 6:11 AM, Kabir Khan wrote:
> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>
>
>> 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.
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.
>>
>> 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 :-)
>>
I think remove+add is fine.
>> 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
>
>
> _______________________________________________
> 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
11:53 a.m.
On 2 Apr 2015, at 17:17, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On 4/2/15 6:11 AM, Kabir Khan wrote:
>
>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>>
>>
>>> 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.
> 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?
>>>
>>> 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 :-)
>>>
I think remove+add is fine.
>>> 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
>>
>>
>> _______________________________________________
>> 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
noon
On 4/2/15 11:53 AM, Kabir Khan wrote:
> On 2 Apr 2015, at 17:17, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
>
> On 4/2/15 6:11 AM, Kabir Khan wrote:
>>
>>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>>>
>>>
>>>> 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.
>> 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
7:16 a.m.
Hi,
I am adding a domain test to my indexed add stuff, and noticed the following in the
inherited domain operations branch. However, it also seems to happen in master. The steps
to reproduce are:
# Start a DC and a slave
# Reload the DC to admin only
[domain@localhost:9990 /] /host=master:reload(admin-only=true)
# Change something in a subsystem
[domain@localhost:9990 /] /profile=default/subsystem=logging/logger=test:add
# Reload the DC to be normal, so that the changes get applied
[domain@localhost:9990 /] /host=master:reload(admin-only=false)
# Now the changes are in the domain model and servers
[domain@localhost:9990 /]
/profile=default/subsystem=logging:read-children-names(child-type=logger)
{
"outcome" => "success",
"result" => [
— SNIP --
"test"
]
}
[domain@localhost:9990 /]
/host=master/server=server-one/subsystem=logging:read-children-names(child-type=logger)
{
"outcome" => "success",
"result" => [
— SNIP --
"test"
]
}
# They are also in the slave’s copy of the domain model
[domain@localhost:9990 /] connect remote://localhost:19999
[domain@localhost:19999 /]
/profile=default/subsystem=logging:read-children-names(child-type=logger)
{
"outcome" => "success",
"result" => [
— SNIP --
"test"
]
}
# But they are NOT in the slave server’s subsystem
[domain@localhost:19999 /]
/host=localhost/server=server-one/subsystem=logging:read-children-names(child-type=logger)
{
"outcome" => "success",
"result" => [
"com.arjuna",
"jacorb",
"jacorb.config",
"org.apache.tomcat.util.modeler",
"org.jboss.as.config",
"sun.rmi"
]
}
# And the slave seems to have a normal state
[domain@localhost:19999 /]
/host=localhost/server=server-one:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"host" => "localhost",
"launch-type" => "DOMAIN",
"management-major-version" => 3,
"management-micro-version" => 0,
"management-minor-version" => 0,
"name" => "server-one",
"namespaces" => [],
"process-type" => "Server",
"product-name" => undefined,
"product-version" => undefined,
"profile-name" => "default",
"release-codename" => "Kenny",
"release-version" => "1.0.0.Beta4-SNAPSHOT",
"running-mode" => "NORMAL",
"schema-locations" => [],
"server-group" => "main-server-group",
"server-state" => "running",
"suspend-state" => "RUNNING",
— SNIP --
}
}
I will attempt to fix this on the domain operations branch. Do we want to put the servers
on the slave into reload-required, or should I propagate the operation to those?
On 2 Apr 2015, at 18:00, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On 4/2/15 11:53 AM, Kabir Khan wrote:
>
>> On 2 Apr 2015, at 17:17, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>
>> On 4/2/15 6:11 AM, Kabir Khan wrote:
>>>
>>>> On 2 Apr 2015, at 11:01, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>>>>
>>>>
>>>>> 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.
>>> 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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:22 a.m.
It's possible I'm misunderstanding, but would the using a comparator [1]
in the describe handler work?
[1]:
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
On 04/01/2015 05: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
--
James R. Perkins
JBoss by Red Hat
5:27 a.m.
On 6 Apr 2015, at 16:22, James R. Perkins <jperkins(a)redhat.com>
wrote:
It's possible I'm misunderstanding, but would the using a comparator [1]
in the describe handler work?
No :-)
[1]:
https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j...
On 04/01/2015 05: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
--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3551
days inactive
3557
days old
9 comments
3 participants
participants (3)
-
Brian Stansberry -
James R. Perkins -
Kabir Khan