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
----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
> To: wildfly-dev(a)lists.jboss.org
> Sent: Monday, July 13, 2015 12:11:22 PM
> Subject: [wildfly-dev] Recursive management resource removes
> 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
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 . This is expected to be a quite unusual
> thing to do.
> If your resource doesn't use AbstractRemoveStepHandler for implementing
> 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.
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> wildfly-dev mailing list