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

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.

>> 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 >