[wildfly-dev] Preparation for requirements and capabilities.

[Darran Lofthouse]

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.

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.

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