[wildfly-dev] Preparation for requirements and capabilities.

[Brian Stansberry]

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