[wildfly-dev] Core and subsystem capabilities and requirements
Jeff Mesnil
jmesnil at redhat.com
Thu Jul 3 05:56:52 EDT 2014
On 23 Jun 2014, at 22:38, Kabir Khan <kabir.khan at jboss.com> wrote:
>
> 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 think we have such an use case in the messaging subsystem.
We will have a MESSAGING:CLUSTERED capability that will provide clustered messaging.
This capability may require JGROUPS:BASE capability to use the JGroups stack but it is not mandatory since HornetQ also provides its own UDP stack that can be used if JGroups is not there.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
More information about the wildfly-dev
mailing list