[wildfly-dev] Preparation for requirements and capabilities.

[Darran Lofthouse]

On 25/03/15 16:01, Brian Stansberry wrote:
> On 3/25/15 10:41 AM, Darran Lofthouse wrote:
>>
>>
>> On 25/03/15 15:34, Brian Stansberry wrote:
>>> On 3/25/15 10:28 AM, Darran Lofthouse wrote:
>   >>>
>>>> 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
>>
>> What I mean here is, my security realm would have both a name for the
>> capability name e.g. org.wildfly.security.security_realm and a name for
>> the instance, e.g. CorporateRealm.
>>
>> For those examples if you don't have an instance name then yes I see
>> exclusivity would be needed - those are following the lines of "I am the
>> servers IIOP Provider"
>>
>
> Maybe that distinction will work.  It initially felt a bit like
> stretching an abstraction to cover something else. But if you conceive
> of both of these cases as needing to produce a unique name, but in the
> named instance case the last element of the name just happens to be
> dynamic, then it works and seems simpler.
>
> Only one of these is allowed in a context
>
> org.wildfly.extension.iiop
> org.wildfly.extension.security.security-realm.foo
> org.wildfly.extension.security.security-realm.bar

That seems reasonable to me, any tooling can probably use whatever ops 
are provided to discover existing security realms to assist the user in 
ensuring the name they give their new security realm is actually unique 
across the context.

>
> How those strings are constructed is a separate issue. The first is
> static, the latter two are a static prefix and a dynamic suffix.
>
>
>