[
https://issues.jboss.org/browse/WFLY-2609?page=com.atlassian.jira.plugin....
]
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