11:11 a.m.
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/7a046d7b99eeb1a73b53253786a...
[2]
https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8...
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat