3:24 p.m.
On 3/19/15 12:08 PM, Darran Lofthouse wrote:
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.
I like the notion of both the capability code and the requiring code
turning over the mechanics of service name creation to the core. I
expect that will go into the OperationContext though, as it has the
knowledge of what capabilities exist. If it's purely a mechanical
function though with no validation required it could just go in some
static method somewhere, but it's likely in the real use cases there
will be some validation.
I don't see a type as being valid data for creating a ServiceName. There
isn't a 1:1 correspondence between a type and the various things that
can provide services whose value is of that type. Simplest case being
Service<Void>, but I bet we have some Service<String> out there.
If we limit a capability to providing just a single type for injections,
then it can just be:
public ServiceName getServiceName(String capability, String instanceName)
A capability provides a namespace, as does the prefix for a ServiceName
so it seems reasonable enough to me to reuse one for the other.
Particularly if it's all hidden behind a method the core provides.
I was a bit reluctant to limit a capability to providing just a single
injection type, as there are some cases where it's a bit fine grained.
For example IIOP provides both an ORB and a CORBA NamingContextExt. But
I don't think there are enough such cases to outweigh the simplicity
advantages of having a single injection type per capability.
> 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
>
_______________________________________________
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