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