[wildfly-dev] Core and subsystem capabilities and requirements

[Brian Stansberry]

On 6/23/14, 2:52 PM, David M. Lloyd wrote:
> On 06/23/2014 01:20 PM, Brian Stansberry wrote:
>> As we continue with our work splitting the WildFly code base into a core
>> repo and then separate repos related to sets of features that we need to
>> solidify the contracts between the various features and between features
>> and the core.
>>
>> I've taken a crack at an initial design document on this: see [1]. We
>> also need to do the practical work of identifying the various
>> dependencies between our existing subsystems, see [2] for a start on that.
>>
>> I'd love to get feedback on this thread regarding the proposed design,
>> as well as get direct edits on the [2] doc to flesh out the existing
>> relationships.
>
> Here is what jumps out at me at first.
>
> • I don't understand the reason to not allow optional dependencies on
> capabilities.  It would be of similar implementation complexity to the
> suggested permutation implementation, however it would avoid the problem
> of requiring 2ⁿ permutations for n optional dependencies.
>

I knew that would draw some comment and was already backing off it a bit 
as I wrote various drafts. :)

The main thing is, say the user declares they want capability A, which 
requires B and C. Then they say they want capability C. Did they forget 
B or do they really not want it?

In the runtime case, there's no problem. The user is actually providing 
a full configuration, and it's clear exactly what they need.

In the provisioning case, it's a bit less clear what they want. But it's 
a valid requirement to say "you must declare B" if you want it.

> • I don't understand the purpose of binding capability identifiers to
> subsystem identifiers.  It seems plausible to have a subsystem provide,
> for example, two capabilities now, but allow for a capability to be
> implemented separately in the future.  A concrete example would be the
> way we ultimately moved Servlet from JBoss Web to Undertow.  Ideally
> we'd only ever depend on the capability, making subsystems completely
> interchangeable.
>

See your question about uniqueness. Associating these with subsystems 
provides a form of namespacing; without that we'd have to come up with 
something else.

It's a valid point that we don't have to use association with subsystems 
to provide this though. Any other suggestions?

> • I do think we should set up capabilities for things in the core model
> (outside subsystems), especially as we seem to always increase the
> number of things that can't be in subsystems (a trend I hope we can
> reverse in the future).
>

Yes, I assume we will need to as well.

> • Can you define what having a capability be "provided by default"
> means?  Or perhaps more aptly, what it means to *not* be provided by
> default?
>

I'm not sure which of these you're asking about, or maybe something 
else. So I'll answer a couple things:

"default. boolean indicating whether a capability is provided by 
default. Always true for a base capability (i.e. if a subsystem is 
present, its base capability is as well.) Usage would be for the 
provisioning use case described below, to reduce the amount of 
information a user would need to provide to get a typical configuration. 
TBD whether this make sense."

Say an infinispan subsystem provides a base capability that is local 
caching only and also a clustered caching capability that requires 
jgroups. 98% of the time a user who wants infinispan wants clustered 
caching, so having it there by default saves a user who tells the 
provisioning tool they want the extension also having to say they want 
that capability. The 2% user who doesn't want that capability would need 
to indicate that somehow in the spec they provide to the tool.

"Subsystems are only required to register a base capability if it either 
depends on some other capability or exposes a runtime API. Otherwise, a 
default base capability will be registered automatically at the end of 
Stage.MODEL. (TBD: not certain is this default registration provides any 
value.)"

Say a subsystem like jdr, which currently no one depends on. Does it 
need to declare that it provides the "jdr" capability? Or can that just 
be implicit?

This really depends on whether 1) there is any value in providing a 
complete list of capabilities and 2) it's worthwhile not requiring a 
subsystem to explictly declare a capability, but instead to just provide 
a default one.

Re: 1) I was thinking about things like an installer/provisioning tool. 
We don't want users thinking in terms of "I want these 4 capabilities, 
and, oh, I also want these 3 subsystems too." Users should be able to 
represent everything in terms of capabilities. So my answer to 1) is "yes".

Re: 2) if we decide capabilities are not bound to subsystems, then 
there's no choice; a subsystem will have to declare a capability.

> • What about uniqueness?  Can/should we enforce that each capability is
> only ever satisfied by one subsystem?
>

In a given context (e.g. a server or a domain profile), yes.

>> [1] https://community.jboss.org/docs/DOC-52712
>>
>> [2] https://community.jboss.org/docs/DOC-52700
>>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat