Re: [wildfly-dev] Core and subsystem capabilities and requirements
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 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.
• 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).
• 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?
• What about uniqueness? Can/should we enforce that each capability is
only ever satisfied by one subsystem?
--
- DML