[jboss-jira] [JBoss JIRA] (WFCORE-1269) Resource passed into RootDeploymentUnitService is decoupled from official model

[Brian Stansberry (JIRA)]

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

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)