[wildfly-dev] Ordered child resources
Kabir Khan
kabir.khan at jboss.com
Tue Apr 7 08:16:30 EDT 2015
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 at localhost:9990 /] /host=master:reload(admin-only=true)
# Change something in a subsystem
[domain at localhost:9990 /] /profile=default/subsystem=logging/logger=test:add
# Reload the DC to be normal, so that the changes get applied
[domain at localhost:9990 /] /host=master:reload(admin-only=false)
# Now the changes are in the domain model and servers
[domain at localhost:9990 /] /profile=default/subsystem=logging:read-children-names(child-type=logger)
{
"outcome" => "success",
"result" => [
— SNIP --
"test"
]
}
[domain at 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 at localhost:9990 /] connect remote://localhost:19999
[domain at 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 at 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 at 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 at redhat.com> wrote:
>
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
More information about the wildfly-dev
mailing list