Re: [wildfly-dev] Core and subsystem capabilities and requirements

On 23 Jun 2014, at 21:31, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > > On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev