On 13 Jul 2015, at 18:11, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: 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.

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... Paul ----- Original Message ----- > From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; > To: wildfly-dev(a)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/7a046d7b99eeb1a73b53253786a... > [2] > https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8... > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >