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 . We
> also need to do the practical work of identifying the various
> dependencies between our existing subsystems, see  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  doc to flesh out the existing
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
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
See your question about uniqueness. Associating these with subsystems
provides a form of namespacing; without that we'd have to come up with
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
(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
means? Or perhaps more aptly, what it means to *not* be provided by
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
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
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
only ever satisfied by one subsystem?
In a given context (e.g. a server or a domain profile), yes.
Senior Principal Software Engineer
JBoss by Red Hat