]
Brian Stansberry commented on WFCORE-788:
-----------------------------------------
Maybe the discard of the model wasn't happening; maybe it was; I'm not sure.
I'll fix that separately. But I think the main problem here is the clone of the
CapabilityRegistry wasn't deep enough. The RuntimeCapabilityRegistration isn't
cloned so mutations made by the first op are visible in the original registry even after
the cloned registry is discarded.
Executing a composite operation allowing services to restart fails if
the first operation relies on a capability of a remove operation
--------------------------------------------------------------------------------------------------------------------------------------
Key: WFCORE-788
URL:
https://issues.jboss.org/browse/WFCORE-788
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: James Perkins
Assignee: Brian Stansberry
This does seem to be somewhat of an edge case as the only way to reproduce it is to add
the {{allow-resource-service-restart=true}} header to a composite operation. The first
operation must also need access to a capability provided by a resource being removed.
It's likely an acceptable failure, but the failure isn't seen when executing the
same composite operation again.
The issue seems to be that the [capability is
removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...]
on the first execution that fails and is rolled back. On the second execution of the
composite operation there is no [capability
registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...]
registered in the {{RuntimeCapabilityRegistration}} so the
[
remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...]
of the capability doesn't happen. This allows the first operation to pass.