Re: [wildfly-dev] Preparation for requirements and capabilities.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat