[jboss-jira] [JBoss JIRA] (WFCORE-1269) Resource passed into RootDeploymentUnitService is decoupled from official model
[
https://issues.jboss.org/browse/WFCORE-1269?page=com.atlassian.jira.plugi...
]
Brian Stansberry resolved WFCORE-1269.
--------------------------------------
Resolution: Won't Do
I've decided not to try and fix this, at least not via keeping this resource in sync.
The problem is for this to work properly, the resource cached in the DeploymentUnit would
have to have visibility to unpublished changes being made by subsequently executing ops,
not just to the changes made once the subsequent op commits. And making that change would
be too problematic
For example, in the WFLY-4908 case an undeploy op affecting deployment 1 is triggering MSC
to stop services for deployment 2, and then a later deploy op for deployment one causes
MSC to start the services for deployment 2. Neither the undeploy or deploy ops directly
relate to deployment 2. But because of the MSC dependency, the deployment 2 DUPs run
during both. But the DUP don't have a ref to the currently unpublished resource tree
used by those ops.
I'm closing this and am going to open a different issue for a minor change to help
avoid the need for things like Scott's WFLY-4908 fix.
Resource passed into RootDeploymentUnitService is decoupled from
official model
-------------------------------------------------------------------------------
Key: WFCORE-1269
URL: https://issues.jboss.org/browse/WFCORE-1269
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Server
Affects Versions: 2.0.5.Final
Reporter: Brian Stansberry
When DeploymentHandlerUtil.doDeploy passes the Resource for the deployment into
RootDeploymentUnitService, it is from the currently executing management ops version of
the resource tree, and becomes the "official" version once that op commits. But
once another config write op commits, the Resource instance cached by the
RootDeploymentUnitService and attached by it to the DeplopymentUnit is no longer the
official copy; it's a previous copy, aka "cruft". So any mutation to it is
not affecting the official copy.
Where this can be an issue is if the deployment services stop or restart due to MSC
dependency changes (i.e. some service depended upon by the deployment stops or restarts),
but not due to deploy/undeploy/redeploy ops affecting the deployment directly. The
stop/restart will trigger the DUPs which then may attempt the out of date
"cruft" Resource.
WFLY-4908 is an example of such modification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)