[wildfly-dev] Preparation for requirements and capabilities.

Darran Lofthouse darran.lofthouse at jboss.com
Thu Mar 19 13:08:57 EDT 2015


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


More information about the wildfly-dev mailing list