[wildfly-dev] Preparation for requirements and capabilities.

[Darran Lofthouse]

My first questions in this area are - What are the constraints going to 
be about unique naming of capabilities?  Will the implementation / API 
provide methods a subsystem can use to help enforce this?

When it comes to resource definitions the definition can either be 
focused on the implementation behind the service or the type the service 
returns.  My preference is to focus on the implementation.

As an example I have a few different security realm implementations: -

keystore-realm=*
ldap-realm=*
jaas-realm=*

All of these would register a service that returns 'SecurityRealm' so 
'SecurityRealm' would be the capability.

So this is really the basis of my question as now the model does not 
enforce unique names.  The reason for this type of split is so each can 
have it's own set of attribute definitions.

If I turned this on it's head and have: -

security-realm=*

Now the model will enforce unique names within my subsystem but I have 
lost the association of type specific attributes.  A security realm 
could support all attribute types but now it becomes hard to work with 
and understand what does what depending on the type.  Or I could add a 
child resource for type specific settings but that moves away from my 
aim of a 1:1 mapping between resource and service.

Although the model enforces unique names this is specific to my 
subsystem only, if another subsystem is also capable of supplying 
SecurityRealm implementations duplicates are again possible.

So overall my preference would be let capabilities and requirements 
worry about naming constraints and leave subsystem implementations to 
focus on understandable typed resources.

Regards,
Darran Lofthouse.




On 24/03/15 14:41, Brian Stansberry wrote:
> 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
>>
>
>