[wildfly-dev] Preparation for requirements and capabilities.

Darran Lofthouse darran.lofthouse at jboss.com
Tue Mar 24 10:28:27 EDT 2015



On 24/03/15 13:48, Brian Stansberry wrote:
> On 3/19/15 5:20 AM, 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.
>>
>
> I'll respond to your second post separately.
>
> I'll be getting back to the capability and requirement stuff full time
> as soon as I'm done with WFCORE-282; hopefully I'll finish that this week.
>
> Are the types Elytron will provide even available, with impls available
> that the current code can also provide? If so, then I guess what you are
> looking for is some way to switch how the service names are determined
> so when Elytron comes in it all just works?
>
>> 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.

The types will be referenceable without the subsystem i.e. we are 
talking about standard Java types or types defined within the Elytron 
project.  Without the subsystem the impls will not exist, the point 
being that once resources reference a named capability it will need to 
exist but until that point it is an optional reference.

We will have some transitioning between old and new but my main point 
here is everything that gets secures will need to know about Elytron but 
nothing should know about it's subsystem.


> That's definitely my intent; information about the available
> capabilities will be available as management resources, including the
> instance names registered in each capability's namespace. "Model
> reference" attributes will include in their metadata the name of the
> capability they reference. With that data available the CLI tab
> completion stuff should be able to determine the currently available names.
>
> I don't see this aspect as blocking Elytron work in any way though. It's
> a feature that would have been useful in many areas since AS 7.0.

+1 This one is not blocking Elytron work, this part of the questions is 
more to check if there is anything I can be doing to assist this but it 
sounds like that may not be necessary.

>> Regards,
>> Darran Lofthouse.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


More information about the wildfly-dev mailing list