[wildfly-dev] Recursive management resource removes

[Brian Stansberry]

Yep. Those are the "couple remove handler impls that have implemented
similar logic in a custom manner" I mentioned. Thanks for those; I saw 
them again when looking at the HASingleton stuff and that was the 
impetus to get this cleared up. I also shamelessly stole your approach 
of adding steps.

On 7/14/15 6:54 AM, Paul Ferraro wrote:
> This is great.  I had already proposed making this the default remove behavior for all clustering resources in https://github.com/wildfly/wildfly/pull/7407 via:
> https://github.com/pferraro/wildfly/blob/infinispan/clustering/common/src/main/java/org/jboss/as/clustering/controller/RemoveStepHandler.java
>
> Paul
>
> ----- Original Message -----
>> From: "Brian Stansberry" <brian.stansberry at redhat.com>
>> To: wildfly-dev at lists.jboss.org
>> Sent: Monday, July 13, 2015 12:11:22 PM
>> Subject: [wildfly-dev] Recursive management resource removes
>>
>> tl;dr
>>
>> We're going to start ensuring that any time a resource is removed, all
>> it's children are properly removed too.
>>
>> This will let users remove an entire profile from the domain config in
>> one op, which in important now that we make it easier to clone an entire
>> profile or include one profile in another. These features should mean
>> people will be more likely to perform major configuration surgery via
>> the management API instead of xml editing, and surgeons need to 'remove'
>> large chunks.
>>
>> Long version
>>
>> Just an FYI on pending changes in how 'remove' management operations are
>> handled in WildFly 10.
>>
>> First, any resource that represents persistent configuration must expose
>> a no-arg 'remove' operation. This was an informal requirement before;
>> now it's formal.
>>
>> Second, you'd think that if a resource is removed via a 'remove' op that
>> we'd *always* ensure that all child resources are properly removed as
>> well. "Properly" meaning necessary runtime changes are made (e.g.
>> services removed), not just that the resource is dropped from the
>> configuration model.
>>
>> But this isn't the case. There are a couple resources that explicitly
>> reject the 'remove' request if their children haven't been removed
>> first. There are others where the Stage.RUNTIME logic handling the
>> removal of the child assumes the parent model is still present, which is
>> an invalid assumption if the parent is removed in the same op. And there
>> are *may* be some where the child resource is just dropped ignoring the
>> need to clean up child services.
>>
>> With https://github.com/wildfly/wildfly-core/pull/880 and
>> https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the
>> base handler class for 'remove' ops (AbstractRemoveStepHandler) will by
>> default add steps to recursively remove any child resources before
>> executing a step to remove the target resource.
>>
>> If for some reason you don't want a step added to remove a particular
>> child, override the
>> AbstractRemoveStepHandler.removeChildRecursively(PathElement child)
>> method. For example, see [1]. This is expected to be a quite unusual
>> thing to do.
>>
>> If your resource doesn't use AbstractRemoveStepHandler for implementing
>> 'remove':
>>
>> 1) Why not?
>> 2) You're responsible for implementing the same semantic.
>>
>> Note there are a couple remove handler impls that have implemented
>> similar logic in a custom manner. Once a core release with WFCORE-808 in
>> it is in full, that custom logic can be dropped.
>>
>> [1]
>> https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33
>> [2]
>> https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798
>> --
>> 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
>>


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