[jboss-jira] [JBoss JIRA] (WFCORE-3083) Capability reload-required tracking breaks down if the cap is reload-required because of removal

[Brian Stansberry (JIRA)]

Brian Stansberry created WFCORE-3083:
----------------------------------------

             Summary: Capability reload-required tracking breaks down if the cap is reload-required because of removal
                 Key: WFCORE-3083
                 URL: https://issues.jboss.org/browse/WFCORE-3083
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Critical


The WFCORE-1106 fix has a big flaw in how it tracks what capabilities are affected when a resource reports reload-required or restart-required. It only examines currently registered caps, but in the resource removal case the op that is calling reloadRequired() will have removed the cap in an earlier stage. So the fact the cap should be reload-required is not recorded.

The WFCORE-1106 integration test doesn't capture this because it uses write-attribute ops to trigger reload-required.

I discovered this when manually verifying the WFLY-4970 scenario was fixed. Turns out it wasn't.

I think the simple solution is to have the CapabilityRegistry cache the removed capabilities and also use that cache when checking what caps are affected by reload/restart required. The cache can be cleared on each publish or rollback of the registry because the data does not need to be retained beyond the span of the op that is making the changes.



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