[jboss-jira] [JBoss JIRA] (WFLY-2609) ExtensionRegistry.DeploymentManagementResourceRegistration returns incorrect type from getSubModel

[Brian Stansberry (JIRA)]

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

Brian Stansberry updated WFLY-2609:
-----------------------------------

    Description: 
The intended behavior where any modification to the ManagementResourceRegistration tree rooted in deployment=* also gets written to to the deployment=*/subdeployment=* tree is not being consistently applied.

This behavior is implemented by using an MRR implementation class called DeploymentManagementResourceRegistration for the tree rooted in deployment=*. But there are two problems with this:

1) DMRR is only used as a wrapper exposed to callers of Extension.initiatilize(). However, that isn't the only place extensions register deployment MRRs. Some also do it inside DeploymentUnitProcessors or DUP initialized services. These callers are not getting a DMRR, so their modifications are not applied to both trees.

2) DeploymentManagementResourceRegistration.getSubModel() and getOverrideModel() are not returning another DeploymentManagementResourceRegistration. Instead they are returning the normal ManagementResourceRegistration in the "deployments" tree. So, if a caller invokes those methods and then makes modifications, the modifications are not applied to both trees.

This is showing up as an issue in the JPA subsystem, which defers registration of part of its model to DUPs.

  was:
DeploymentManagementResourceRegistration.getSubModel() and getOverrideModel() are not returning another DeploymentManagementResourceRegistration. Instead they are returning the normal ManagementResourceRegistration in the "deployments" tree.

The effect of this is if getSubModel() is called, and then the returned MRR is modified, the modification only happens in the deployment tree instead of being copied to both it and the subdeployment tree by the special DeploymentManagementResourceRegistration logic.

This is showing up as an issue in the JPA subsystem, which defers registration of part of its model and calls getSubModel() when it needs to do the registration.


    
> ExtensionRegistry.DeploymentManagementResourceRegistration returns incorrect type from getSubModel
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2609
>                 URL: https://issues.jboss.org/browse/WFLY-2609
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The intended behavior where any modification to the ManagementResourceRegistration tree rooted in deployment=* also gets written to to the deployment=*/subdeployment=* tree is not being consistently applied.
> This behavior is implemented by using an MRR implementation class called DeploymentManagementResourceRegistration for the tree rooted in deployment=*. But there are two problems with this:
> 1) DMRR is only used as a wrapper exposed to callers of Extension.initiatilize(). However, that isn't the only place extensions register deployment MRRs. Some also do it inside DeploymentUnitProcessors or DUP initialized services. These callers are not getting a DMRR, so their modifications are not applied to both trees.
> 2) DeploymentManagementResourceRegistration.getSubModel() and getOverrideModel() are not returning another DeploymentManagementResourceRegistration. Instead they are returning the normal ManagementResourceRegistration in the "deployments" tree. So, if a caller invokes those methods and then makes modifications, the modifications are not applied to both trees.
> This is showing up as an issue in the JPA subsystem, which defers registration of part of its model to DUPs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira