Re: [wildfly-dev] Preparation for requirements and capabilities.

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.