[
https://issues.jboss.org/browse/WFCORE-1483?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-1483:
------------------------------------------
A possibility here is to use the OperationDefinition data associated with the handler for
each remove to see if the op will require-reload. That is, the kernel doesn't wait for
the remove OSH to call context.reloadRequired() in order to know that reload is required,
as that call happens too late. Too late because the Stage.RUNTIME call (i.e. invocation of
performRuntime(...)) for the parent resource will happen *after* the Stage.RUNTIME call
for the children. What's needed is to have an expectation for the parent and all
descendants before *any* of them get to their performRuntime() handling.
Still tricky though. The mechanism to communicate state between the relevant steps (but
not to other steps) also doesn't exist.
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 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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)