]
Brian Stansberry updated WFCORE-3327:
-------------------------------------
Summary: Confusion about the recording of the org.wildfly.remoting.endpoint capability
and the resource that configures it (was: Confusing between recording of the
org.wildfly.remoting.endpoint and the resource that configures it)
Confusion about the recording of the org.wildfly.remoting.endpoint
capability and the resource that configures it
-----------------------------------------------------------------------------------------------------------------
Key: WFCORE-3327
URL:
https://issues.jboss.org/browse/WFCORE-3327
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Remoting
Affects Versions: 3.0.3.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 4.0.0.Beta1
The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting
resource, but it is the /subsystem=remoting/configuration=endpoint that actually
configures it. This is confusing for humans and difficult for tooling like the new
provisioning tools.
The configuration=endpoint child is essentially a singleton and internally it just
provides configuration to its parent. Further, if the user does not configure this
resource, a default one is added automatically. This child resources is really just a
configuration chunk for its parent.
In the end it is the parent resource that actually provides the capability, by installing
a service. It reads its child resource to configure the capability.
There are a couple possibilities here:
1) Simply move the declaration of the capability to the child resource. Per discussion
with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation
obscure though, because now a seemingly non-required child resource is the thing that
provides a capability that actually will always be present.
2) Deprecate that child resource and add a complex attribute to the parent. The child
resource continues to exist in the API for compatibility reasons, but simply modifies the
attribute on the parent. The cap remains on the parent.
Note that 2) may require some manipulation of how we handle undefined complex attributes;
i.e. that when we resolve them, even if the root attribute is undefined, we need to
resolve the fields, in case those have default values, with the resolved parent then
including the default field values. That can be tricky though, e.g. in cases of things
like the defaulted attribute having requires, or other fields in the complex attribute
being required.
This latter point is relevant because it would be a 'worker' field in a complex
attribute that would actually declare the name of the needed io worker capability. That
field would have a default value 'default'.
Perhaps the declaration of the complex attribute itself (i.e.
ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That
could just be the complex attribute itself has a default value,
{"worker"=>"default"}. Or it could be a flag that enables looking
at the fields for defaults if the top level attribute is undefined. Or maybe investigation
will show this isn't a problem at all.