Re: [wildfly-dev] Preparation for requirements and capabilities.

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