[wildfly-dev] Core and subsystem capabilities and requirements

[Jason Greene]

On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd at redhat.com> 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 had the same thought.

> 
> • 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 think Brian was trying to allow for thirdparty subsystems to potentially collaborate without a global registration (like we have with Phases). In practice I would imagine all of our out of the box subsystems would be using null. Alternatively we could just use some kind of ad-hoc string as a group name or something.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat