[wildfly-dev] Preparation for requirements and capabilities.

[David M. Lloyd]

On 03/25/2015 09:35 AM, Brian Stansberry wrote:
> On 3/25/15 9:15 AM, David M. Lloyd wrote:
>> On 03/24/2015 03:11 PM, Brian Stansberry wrote:
>>> On 3/24/15 1:08 PM, Darran Lofthouse wrote:
>>>> My first questions in this area are - What are the constraints going to
>>>> be about unique naming of capabilities?
>>>
>>> They must be namespaced. See
>>> https://developer.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements.
>>>
>>> The ones we provide must be in the org.wildfly namespace, which is
>>> reserved for us. Use org.wildfly.extension.xxxx for stuff this is
>>> provided by an extension, and isn't part of the kernel.
>>>
>>> (OT: I'm going to start using the term 'kernel' to mean what used to be
>>> called the 'core' since now WildFly Core means the kernel plus a few
>>> subsystems.)
>>>
>>>> Will the implementation / API
>>>> provide methods a subsystem can use to help enforce this?
>>>>
>>>
>>> The OperationContext will enforce uniqueness. I don't think a subsystem
>>> will help enforce this; the subsystem authors will just create a
>>> reasonable namespace and stick to it.
>>>
>>>> When it comes to resource definitions the definition can either be
>>>> focused on the implementation behind the service or the type the service
>>>> returns.  My preference is to focus on the implementation.
>>>>
>>>> As an example I have a few different security realm implementations: -
>>>>
>>>> keystore-realm=*
>>>> ldap-realm=*
>>>> jaas-realm=*
>>>>
>>>> All of these would register a service that returns 'SecurityRealm' so
>>>> 'SecurityRealm' would be the capability.
>>>>
>>>> So this is really the basis of my question as now the model does not
>>>> enforce unique names.  The reason for this type of split is so each can
>>>> have it's own set of attribute definitions.
>>>>
>>>> If I turned this on it's head and have: -
>>>>
>>>> security-realm=*
>>>>
>>>> Now the model will enforce unique names within my subsystem but I have
>>>> lost the association of type specific attributes.  A security realm
>>>> could support all attribute types but now it becomes hard to work with
>>>> and understand what does what depending on the type.  Or I could add a
>>>> child resource for type specific settings but that moves away from my
>>>> aim of a 1:1 mapping between resource and service.
>>>>
>>>> Although the model enforces unique names this is specific to my
>>>> subsystem only, if another subsystem is also capable of supplying
>>>> SecurityRealm implementations duplicates are again possible.
>>>>
>>>
>>> Within a given context (i.e. a standalone server or a domain profile)
>>> some other subsystem providing a capability with the same name will not
>>> be allowed. If someone else wants to provide access to
>>> Service<SecurityRealm> for some unrelated reason then they need to
>>> provide their own capability name. If they are actually another
>>> implementation of the same capability, then the user has to pick one or
>>> the other within a context.
>>>
>>>> So overall my preference would be let capabilities and requirements
>>>> worry about naming constraints and leave subsystem implementations to
>>>> focus on understandable typed resources.
>>>>
>>>
>>> That's fine. If keystore-realm=* et al are all providing instances of
>>> the same capability, then the OperationContext can enforce that as part
>>> of model validation by detecting duplicate instance names registered
>>> within a single capability namespace.
>>>
>>> Having keystore-realm=*, ldap-realm=*, jaas-realm=* all registering
>>> instance names in the same capability namespace will add some complexity
>>> to the validation though, so thanks for pointing that use case out. The
>>> complexity is discriminating your use case (legal) from two completely
>>> different subsystems using the same namespace in the same context
>>> (illegal). A possible solution is the parent resource for those is what
>>> declares that it provides capability org.wildfly.extension.xxx and then
>>> the kernel accepts instance name registrations from children, while
>>> rejecting them from non-children.
>>
>> 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.

-- 
- DML