[wildfly-dev] Core and subsystem capabilities and requirements
Jason Greene
jason.greene at redhat.com
Mon Jun 23 16:31:04 EDT 2014
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
More information about the wildfly-dev
mailing list