[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

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

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



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