[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

On 3/25/15 10:28 AM, Darran Lofthouse wrote:
>
>
> On 25/03/15 15:00, Brian Stansberry wrote:
>> On 3/25/15 9:54 AM, Darran Lofthouse wrote:
>>>
>>> On 25/03/15 14:44, Brian Stansberry wrote:
>>>> On 3/25/15 9:36 AM, Darran Lofthouse wrote:
>>>>> The case I have now is say the Elytron subsystem is installed and the
>>>>> KeyCloak subsystem is installed - it is quite conceivable that both
>>>>> would provide capabilities for
>>>>> 'org.wildfly.extension.security.security-realm'
>>>>>
>>>>
>>>> That's fine so long as they don't appear in the configuration in the
>>>> same "context". Context meaning the same profile. A domain can have
>>>> both, just not in the same profile. A standalone server of course only
>>>> has one profile.
>>>
>>> I am kind of thinking these would be the same profile, i.e. you could
>>> have security realms defined in Elytron used for one set of deployments
>>> and then KeyCloak could provide a realm used by a different deployment.
>>>
>>> Although we may be able to find a way around this example if we step
>>> back from the realm.
>>>
>>> The Elytron subsystem will be exposing SecurityDomains as a capability,
>>> strictly speaking it is these that secured resources will have a
>>> dependency on.
>>>
>>> A SecurityDomain will reference one or more SecurityRealm instances.  So
>>> within the Elytron subsystem I need to be able to reference security
>>> realms defined within the Elytron subsystem - but also have the ability
>>> to reference security realms defined in other subsystems, but I also
>>> don't want the Elytron subsystem to need knowledge of the other
>>> subsystems beyond values that are set in the model.
>>>
>>> This pattern could also repeat for KeyStore, KeyManager and TrustManager
>>> which are also ideal candidates for other subsystems to provide their
>>> own implementations of.
>>>
>>
>> Hmm, so some sort of non-exclusive capability thing. Or some way that a
>> capability can declare the context in which it must be exclusive, one
>> option being "NONE".
>
> For the capabilities we are talking about at the moment we are really
> talking about named capabilities or model references - for these do we
> have examples where exclusivity would be required?
>

Named capabilities.

Examples where exclusivity is required:

jacorb vs iiop-jdk, both providing IIOP capabilities

web compatibility subsystem vs undertow, both providing various 
HTTP/servlet capabilities

messaging vs the-new-one, both providing JMS


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat