Re: [wildfly-dev] Recursive management resource removes

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