Re: [wildfly-dev] Capabilit integration from services and DeploymentUnitProcessors
On 7/1/15 7:25 AM, Tomaž Cerar wrote:
On Tue, Jun 30, 2015 at 8:30 PM, Brian Stansberry
<brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
2) A capability cannot provide services of > 1 value type. It's nice if
capabilities can represent something that's meaningful to an end user,
and there's no reason why something that's meaningful to an end user
might not expose more than one service to other capabilities. If we
limit capabilities to exposing a single service, then we may end up with
multiple capabilities. See [2] for an example case, where a proposed
"org.wildfly.iiop" (nice and simple for an end user to understand)
installs two services, an ORB and a NamingContextExt.
In cases like this capability should still be one service that would
than depend on two or more services.
and consumer of capability would just get the "aggregator" capability
that would than allow access
to other two services (or properties on service)
Aha! Very good point.
If a capability exposes a custom runtime integration API (i.e. not a
service), there can only be one and then consumers would just invoke
whatever methods were relevant to them. This is analogous.
I'm happy then with 1 service per capability and a single fixed pattern
for creating the service names.
OT: I suspect there will be little need for custom runtime APIs, as in
many cases a service could provide whatever it does.
Thanks,
Brian