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

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 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