>
>
>> The IdentityStore interface (abstract class) must have a method which
>> returns the supported (or list of) Credentials classes. And we can select a
>> suitable one based on this info as explained above.
>> Can you give an example of this?
>> There are a couple of options here I guess, but it does depend a little
>> on whether we want a single store implementation to support more than one
>> credential type. A single credential type would simply be:
>
>
There are indeed multiple options.
I find the fact that you need some xxxAnnotationLiteral isn't very clear
and will be forgotten, which results in AmbiguousResolutionException. If we
do it more in code, you can give better error messages.
When using a method which returns the supported Credentials class is more
expressive (and you don't need an additional annotation)
*public Class<? extends Credential>[] supportForCredentials() {*
* return new Class[]{UsernamePasswordCredentials.class}*
*}*
In any case, CDI can and should be used for this.
Regards
Rudy
On 20 June 2015 at 23:49, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Saturday, June 20, 2015, Rudy De Busscher <rdebusscher_at_gmail.com>
> wrote:
>
>> Arjan,
>>
>> I agree when you say that we should try to use CDI to select the
>> IdentityStrore.
>>
>> But you need a Qualifier for this, and since the UsernamePasswordCredentials
>> for example is a concrete class, it is not usable as qualifier (=
>> annotation)
>>
>
> True, the credentials themselves would normally not be used directly.
>
>
>
>> How are we going to link certain implementation classes with a Qualifier?
>> Or am I missing something?
>>
>
> No, I was just a bit too brief in the example I guess ;)
>
> The idea was just to point out that an annotation literal can be used to
> select a specific implementation. In that example you'd hypothetically
> match a credential type with an annotation literal. So if you used
> UsernamePasswordCredential, you'd use a UserNamePasswordAnnotationLiteral
> to look up an identity store. This assumes that the code instantiating the
> credential would be the same code that does the identity store lookup.
>
> But the example wasn't meant to be used exactly as is, just as mentioned a
> very quick way to show that CDI can do finer grained selections beyond just
> the type of the class.
>
>
>
>> *How I see this working using CDI:*
>>
>> What we can do is to create an annotation (say @IdentityStoreVariant, not
>> a very good name) which has a value parameter which takes the class which
>> will have the credentials, like this
>>
>> *_at_Inject*
>> *_at_IdentityStoreVariant(UsernamePasswordCredentials.class)*
>> *private IdentityStore identityStore;*
>>
>> Now the CDI producer can look at the InjectionPoint info and find the
>> annotation and the requested Credentials class. And select the correct
>> identityStore out of all CDI beans implementing this interface.
>>
>
> Yes, that works ;)
>
> In addition to injection, this form also makes it really easy to look up
> beans which support a given credential type programmatically. Incidentally,
> this is the exact mechanism we use in the JSF 2.3 EG to select beans.
>
> E.g. in UIData.java
>
> cdi.select(e.getValue(), new FacesDataModelAnnotationLiteral(e.getKey())
>
> (e.getValue() is a DataModel implementation class, which has some
> parallels with an IdentityStore here, while e.getKey() is the class the
> DataModel is handling, which has some parallels with the credential type
> here)
>
> See
> https://github.com/omnifaces/mojarra/blob/master/jsf-api/src/main/java/javax/faces/component/UIData.java#L1907
>
> We use this pattern for more things, e.g. Converters, Behaviors and
> Validators are now created like that as well. See e.g.
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/CdiUtils.java#L148
>
>
>
>> The IdentityStore interface (abstract class) must have a method which
>> returns the supported (or list of) Credentials classes. And we can select a
>> suitable one based on this info as explained above.
>>
>
> Can you give an example of this?
>
> There are a couple of options here I guess, but it does depend a little on
> whether we want a single store implementation to support more than one
> credential type. A single credential type would simply be:
>
> @RequestScoped
> @IdentityStoreVariant(UsernamePasswordCredentials.class)
> public class MyStore implements IdentityStore {
>
> // ....
>
> }
>
> Multiple types (with an OR relation for lookup or injection) are a bit
> more work to implement. There's at least a method via extensions and a
> method via producers, which looks as follows:
>
> @RequestScoped
> @IdentityStoreVariant(UsernamePasswordCredentials.class)
> public class MyStore implements IdentityStore {
>
> @Produces
> @IdentityStoreVariant(TokenCredential.class)
> protected IdentityStore token() {
> return this;
> }
>
> // ...
>
> }
>
> Kind regards,
> Arjan Tijms
>