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

On 24/03/15 20:11, 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.) (OT: Personally I wish kernel was it's own build ) > >> 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. I may be thinking of this the opposite way around, or it may be that my capabilities are more ingrained with the application server as a whole. In the case of Elytron I think we have a successful API/SPI separation if we can say the Elytron Subsystem is optional, primarily this gives us two different situations: - - No capabilities provided and nothing requiring them - essentially a completely unsecured server. - An alternative subsystem providing all of the capabilities, maybe this is a pure KeyCloak server or maybe an ISV wants the security tightly built on their product. As I type this having the namespace defined by the subsystem is probably not an issue provided that every place say a security realm can be referenced this is a qualified reference including the namespace. Also the discovery of available security realms would need to take into account different namespaces being available.

(OT: Wonder if we should think about access control here, I am waiting till I have the majority of the model in place to really look into it but we do have the issue of no longer being able to tell which parts of security are app and which parts are management) >> 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. > >> Regards, >> Darran Lofthouse. >> >> >> >> >> On 24/03/15 14:41, Brian Stansberry wrote: >>> On 3/24/15 9:33 AM, Darran Lofthouse wrote: >>>> >>>> >>>> On 24/03/15 14:24, Brian Stansberry wrote: >>>>> On 3/19/15 12:08 PM, Darran Lofthouse wrote: >>>>>> On 19/03/15 10:20, Darran Lofthouse wrote: >>>>>>> Assuming the title still covers the scenarios I have in mind is there >>>>>>> anything we can be doing now to prepare for requirements and >>>>>>> capabilities support to make transitioning easier once it is available. >>>>>>> >>>>>>> As an example within Elytron we will have a number of services that >>>>>>> define either standard types or types defined by API that we want to >>>>>>> inject - is there anything we can do today for subsystems that want to >>>>>>> say "I want a type X, named Y injected here" whilst minimising >>>>>>> interaction with and knowledge of the Elytron subsystem. >>>>>> >>>>>> For the service naming issue I have one idea, I create a utility class >>>>>> in wildfly-core with the following method: - >>>>>> >>>>>> public static ServiceName createServiceName(Class<?> type, >>>>>> String simpleName); >>>>>> >>>>>> The type here is the type that the service returns, this methods >>>>>> constructs a ServiceName taking into account the class name of the type >>>>>> and the supplied simpleName which really is just it's reference. >>>>>> >>>>>> Within the Elytron subsystem I install services by using this method to >>>>>> construct the names. >>>>>> >>>>>> For any other service that depends on one of these types the same method >>>>>> is used when creating the dependency. >>>>>> >>>>>> This way details of the Elytron subsystem do not leak out to other >>>>>> subsystems. >>>>>> >>>>> >>>>> I like the notion of both the capability code and the requiring code >>>>> turning over the mechanics of service name creation to the core. I >>>>> expect that will go into the OperationContext though, as it has the >>>>> knowledge of what capabilities exist. If it's purely a mechanical >>>>> function though with no validation required it could just go in some >>>>> static method somewhere, but it's likely in the real use cases there >>>>> will be some validation. >>>>> >>>>> I don't see a type as being valid data for creating a ServiceName. There >>>>> isn't a 1:1 correspondence between a type and the various things that >>>>> can provide services whose value is of that type. Simplest case being >>>>> Service<Void>, but I bet we have some Service<String> out there. >>>>> >>>>> If we limit a capability to providing just a single type for injections, >>>>> then it can just be: >>>>> >>>>> public ServiceName getServiceName(String capability, String instanceName) >>>>> >>>>> A capability provides a namespace, as does the prefix for a ServiceName >>>>> so it seems reasonable enough to me to reuse one for the other. >>>>> Particularly if it's all hidden behind a method the core provides. >>>>> >>>>> I was a bit reluctant to limit a capability to providing just a single >>>>> injection type, as there are some cases where it's a bit fine grained. >>>>> For example IIOP provides both an ORB and a CORBA NamingContextExt. But >>>>> I don't think there are enough such cases to outweigh the simplicity >>>>> advantages of having a single injection type per capability. >>>> >>>> +1 Take my suggestion extremely lightly, that was only going to be a >>>> temporary step towards being capability based - from your other e-mail >>>> it sounds like that is going to be actively developed now so I can just >>>> use the real thing. >>>> >>> >>> Yes, it will be. I did a fair amount last summer/fall but then hit a >>> point where I wanted to let ideas percolate, plus I had to do a lot of >>> other tasks. But I think enough percolation has happened (including your >>> helpful suggestion above) and the list other stuff I've had to do is >>> getting short. >>> >>>> I am at the point now where I am starting to wire things together in the >>>> server and have just started an incubation fork of wildfly-core for my >>>> development so let me know if there is anything you want me to try out. >>>> >>> >>> Thanks; I'll do that for sure. >>> >>>>>>> Secondly is there anything we can do at the model level regarding >>>>>>> assisting the user with referential integrity, as an example say I am >>>>>>> writing an attribute using the CLI called 'keystore', this is going to >>>>>>> be a reference to a named KeyStore - how about some form of op >>>>>>> associated with that attribute that can dynamically generate the list of >>>>>>> accepted values on demand, e.g. by querying the model and finding out >>>>>>> which KeyStores are actually available. >>>>>>> >>>>>>> Regards, >>>>>>> Darran Lofthouse. >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev