[wildfly-dev] Preparation for requirements and capabilities.

Brian Stansberry brian.stansberry at redhat.com
Tue Mar 24 09:48:43 EDT 2015


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

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.

> Regards,
> Darran Lofthouse.
> _______________________________________________
> 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


More information about the wildfly-dev mailing list