Paul Ferraro created WFCORE-759:
-----------------------------------
Summary: Improve encapsulation of logic for handling ordered resource
children
Key: WFCORE-759
URL:
https://issues.jboss.org/browse/WFCORE-759
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 2.0.0.Alpha4
Reporter: Paul Ferraro
Assignee: Kabir Khan
Currently, a resource that has ordered child resources needs to define this logic in 3
places:
# The ResourceDefinition needs to indicate that it supports indexed adds (solely for
adding the appropriate add-index description) by overwriting
SimpleResourceDefinition.isOrderedChildResource()
# The add operation handler of the parent resource needs to override
AbstractAddStepHandler.getResourceCreator() to provide an implementation of
OrderedResourceCreator that dictates which child types will be ordered
# The add operation handler of the ordered child resource needs to override
AbstractAddStepHandler.getResourceCreator() to provide an implementation of
OrderedResourceCreator that indicates that the resource supports add-index.
IMO, this seems like poor encapsulation. If we added a
ImmutableManagementResourceRegistration.isOrderedChildResource() method, then the
AbstractAddStepHandler can query the resource registration to determine whether the
current resource supports the add-index parameter, and to see which child types are
ordered. This would eliminate the need for subsystems to do #2 and #3 - based solely on
the information provided by #1.
Also, indicating this behavior (i.e. #1) via overriding a protected method also seems a
little hacky/tacked-on. This method is only read by the SimpleResourceDefinition
constructor - which means that this information is more appropriately provided by the
constructor. I assume it was done this way since the SimpleResourceDefinition
constructors are already overly polluted/complex. Why not instead define this behavior by
a ManagementResourceRegistration.registerOrderedSubModel(ResourceDefinition) method?
Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)