[wildfly-dev] Recursive management resource removes

[Brian Stansberry]

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