[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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