[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

On 3/25/15 10:03 AM, David M. Lloyd wrote:
> On 03/25/2015 09:35 AM, Brian Stansberry wrote:
>> On 3/25/15 9:15 AM, David M. Lloyd wrote:
>>>
>>> The thing is that some things will require specific types and some will
>>> allow the general type.  So the simple solution is, each realm shall
>>> register two capabilities, one being the generic security-realm=myname
>>> and the other being type-specific, ldap-realm=myname.  This way things
>>> which allow the generic type can use it, whereas things which require
>>> ldap can require that.  Additional "levels" can be added in the event
>>> that there is a hierarchy of types.  This allows the simpler mechanism
>>> to accommodate complex use cases.
>>>
>>
>> This can certainly work; there's nothing preventing code registering
>> multiple capabilities. The validation issue I mentioned above still
>> applies, but I figure we can sort that.
>>
>> Circling back to the ServiceName discussion, would this be implemented
>> via an alias ServiceName? So there would be a Service<LdapRealm>
>> registered under org.wildfly.extension.security.ldap-realm.foo but then
>> also registered with an alias of
>> org.wildfly.extension.security.security-realm.foo? The consumer of the
>> latter not concerned about/aware of the fact it provides
>> Service<LdapRealm> because LdapRealm is a subtype of SecurityRealm?
>>
>> A provider could do this other ways as well (just create two services)
>> but the above seems feasible.
>
> Is it necessary to have separate MSC namespaces for each capability
> namespace?  Since all security realms would have to ultimately be a
> security-realm, it seems like one MSC namespace could suffice.
>

No, it's not necessary. This ties into a thought I had early in the 
thread. Not necessarily a good one. See

http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003712.html

This is primarily noodling about ease of use concerns. The way the 
capability/requirement stuff currently in core works, the capability 
registers an instance of an API, and then the requirer accesses that API 
and uses it to do service wiring (e.g. determine or ServiceName or even 
to configure the injection on a ServiceBuilder.) The API can provide 
other methods too if the capability involves more than service 
dependencies/injection.

But for the simple case where all that's needed is a simple injection, 
this approach involves quite a lot of boilerplate. Hence the noodling.

Tomaz has attacked the same problem; see 
https://github.com/ctomc/wildfly-core/commit/572763331f4234c504f6f04faf9b2cf7fb5900fd


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