[wildfly-dev] Core and subsystem capabilities and requirements

[Kabir Khan]

On 23 Jun 2014, at 21:31, Jason Greene <jason.greene at redhat.com> wrote:

> 
> 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 really understand what you two are getting at here. What would an optional requirement be? I can’t really get my head around “I would like this to be there but I don’t care if it isn’t”.
> 
>> 
>> • 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
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev