[jboss-jira] [JBoss JIRA] (WFCORE-508) Remove need to maintain discovery-option ordering separately from the option
Brian Stansberry created WFCORE-508:
---------------------------------------
Summary: Remove need to maintain discovery-option ordering separately from
the option
Key: WFCORE-508
URL: https://issues.jboss.org/browse/WFCORE-508
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Alexey Loubyansky
Fix For: 1.0.0.Beta1
The various discovery-option (including the static-discovery variant) are represented as
resources, with the ordering between them maintained in the parent
/host=*/core-service=discovery-options resources.
This is too troublesome for the non-xml filesystem-based persistence stuff Alexey
Loubyansky is working on, and is non-standard in general, as we are striving toward using
lists instead of child resources.
I propose the following:
1) The /host=*/core-service=discovery-options "discovery-options" attribute
should be converted into LIST of OBJECT from the current LIST of STRING.
If we can come up with a good name for an attribute, we can just add a new one and
deprecate the old one, preserving compatibility. But if we do that the old
"discovery-options" attribute can't be writable any longer.
2) The elements in the list can be of varied types. This reflects the fact that there are
varied types of child resources (discovery-option and static-discovery). In the metadata
this will be handled as if a general "discovery-option" type were a complex
object with alternative top level fields. For example in the r-r-d output
{code}
"discovery-options" => {
"type" => LIST,
"value-type" => {
"static-discovery" => {
"alternatives" => ["custom-discovery"],
"type" => OBJECT,
"value-type" => {
"protocol" => {...},
"host" => {...}
"port" => {...}
}
},
"custom-discovery" => {
"alternatives" => ["static-discovery"]
"type" => OBJECT,
"value-type" => {
"code" => {...},
"module" => {...},
"properties" => {...}
}
}
}
}
{code}
3) We should continue to support the existing child resources as a sort of runtime-only
(i.e. not directly persisted) alias into an item in the list. The Resource implementation
for /host=*/core-service=discovery-options dynamically generates these. The persistence
logic completely ignores them.
The problem is the child resource needs a name, while the list elements above really
don't. We could require a superfluous "alias" attribute in the list
elements, and probably we could generate one if one isn't provided. If an alias
isn't provided, the name of the child resource becomes "unaliased-X" where X
is the current index in the list. For a given element this could change though if the list
changes. If people want a consistent name, provide an alias.
With these non-persistent child resources, we can still support the "add"
operation. Invoking it has the result of adding a new element to the list.
The child resources could include an attribute indicating their current list position.
This would be read-only (i.e. no trying to reorder the list by changing this) but perhaps
the "add" op could accept it as a param to indicate the initial position in the
list.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)