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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>