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