[
https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin...
]
Brian Stansberry commented on WFCORE-840:
-----------------------------------------
So, before capabilities, if the resource installed a service A that depended on some
external service Z, but it also installs a second service B, should it record that B
depends on Z? After all, if Z isn't there, the whole thing is going to get rolled
back, so B really does depend a Z.
I'm fine with an overloaded variant of this for the common case where the resource
only has a single capability, assuming the wiring can be worked out. But if there's
ambiguity, it should fail.
Improve API on AttributeDefinitions where a capability is
referenced.
---------------------------------------------------------------------
Key: WFCORE-840
URL:
https://issues.jboss.org/browse/WFCORE-840
Project: WildFly Core
Issue Type: Sub-task
Components: Domain Management
Affects Versions: 2.0.0.Alpha11
Reporter: Darran Lofthouse
Assignee: Tomaz Cerar
Take the following method call defining an attribute: -
{code}
.setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
{code}
This definition says this attribute references something which provides the
PROVIDERS_CAPABILITY.
However it also states that the resource that contains this attributes provides the
SASL_SERVER_FACTORY_CAPABILITY.
Really what the resource provides is not directly related to this attribute definition.
The following pull request has already improved on registering in advance what capability
a resource can provide: -
https://github.com/wildfly/wildfly-core/pull/909
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)