[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

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.


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