[jboss-jira] [JBoss JIRA] (WFCORE-1483) Recursive removal doesn't deal with reload-required cleanly

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1483:
-------------------------------------
    Description: 
There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required.

The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed.

This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive remove, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide. 

  was:
There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required.

The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed.

This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive reload, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide. 



> Recursive removal doesn't deal with reload-required cleanly
> -----------------------------------------------------------
>
>                 Key: WFCORE-1483
>                 URL: https://issues.jboss.org/browse/WFCORE-1483
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> There's a flaw in the WFCORE-808 recursive removal feature when it comes to reload-required.
> The problem is some of the resources recursively removed can require a reload while others don't, with the result that you get a semi-random set of changes to the runtime. This is particularly an issue if the parent resource requires reload and children don't. So based on the parent resource description the user may be expecting no runtime changes but instead some services are removed.
> This is tricky because when the Stage.RUNTIME steps execute for the child resources, they don't know if their parents are going to require a reload. We can probably use a OperationContext attachment of some sort to communicate information between steps associated with a recursive remove, but even with that kind of thing in place, unless we change how AbstractRemoveStepHandler works (likely breaking subclasses) at the time the child decides whether or not to require reload it's not going to know what the parents will decide. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)