[wildfly-dev] Capabilit integration from services and DeploymentUnitProcessors

[Brian Stansberry]

On 7/1/15 7:25 AM, Tomaž Cerar wrote:
>
> On Tue, Jun 30, 2015 at 8:30 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at 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