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

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 >