[wildfly-dev] Recursive management resource removes

[Paul Ferraro]

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/main/java/org/jboss/as/clustering/controller/RemoveStepHandler.java

Paul

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: wildfly-dev at 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/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33
> [2]
> https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>