Hi Arjan,
Indeed, the Alternative approach works (thx, I often forget about
alternatives :) ). And yes, extending an implementation specific class like
DefaultIdentityStoreHandler would tie it to Soteria.
But what I would like to reduce, is the amount of code/configuration a
developer needs to make, to have a custom version.
So then an abstract superclass (where the different stores are retrieved
and split into Authentication/Both and Authorization) could already help.
It would also help the implementers in having a uniform functionality
experience between API implementations.
I'll prepare also a pull request for some small API polishing things around
the multi-store code.
Thx
Best regards
Rudy
On 2 November 2016 at 11:33, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi Rudy,
>
> On Tue, Nov 1, 2016 at 10:09 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
> wrote:
>
>> But since the DefaultIdentityStoreHandler is registered as CDI bean
>> within the CdiExtension , there is an issue when we want to make a
>> custom version of it.
>>
>> *Using @Specializes fails*
>>
>
> @Specializes is likely not the right vehicle here. The default identity
> store handler is implementation specific, so that would necessitate a
> dependency on the org.glassfish package from application code.
>
> A global alternative based on the interface IdentityStoreHandler does work:
>
> import javax.annotation.Priority;
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.inject.Alternative;
> import javax.interceptor.Interceptor;
> import javax.security.identitystore.CredentialValidationResult;
> import javax.security.identitystore.IdentityStoreHandler;
> import javax.security.identitystore.credential.Credential;
>
> @Alternative
> @Priority(Interceptor.Priority.APPLICATION)
> @ApplicationScoped
> public class AlternativeHandler implements IdentityStoreHandler {
> @Override
> public CredentialValidationResult validate(Credential credential) {
> return null; // implement whatever
> }
>
> }
>
> It also works using a @Produces method, like I wrote about here:
> http://jdevelopment.nl/providing-alternatives-jsf-23s-injected-artifacts
>
> Hope that helps!
>
> Kind regards,
> Arjan Tijms
>
>
> p.s.
>
>
>
>> As I remember correctly, the usage of a CDI Extension to register beans,
>> is required when Soteria (or any framework using CDI) is defined as
>> 'module' on the server because these aren't scanned.
>>
>
> True, but note that there's also the "register(@Observes
> BeforeBeanDiscovery beforeBean, BeanManager beanManager) {
> addAnnotatedTypes ...".
>
> That adds an annotated type really early in the CDI startup process and
> makes the type available for "regular" scanning, basically as-if CDI would
> encounter it directly in an archive.
>
> If a bean for the type doesn't have to be added conditionally (e.g. based
> on an other annotation) then adding it fully using addAnnotatedTypes is
> typically the easier way.
>
> Also note that internally CDI creates Bean<T> instances for every
> "regular" CDI bean as well. If you diff what CDI normally would do for a
> scanned bean and what you are doing manually, you could get the same effect.
>
> I.e. the Bean<T> you create manually has this:
>
> new CdiProducer<IdentityStoreHandler>()
> .scope(ApplicationScoped.class)
> .beanClass(IdentityStoreHandler.class)
> .types(Object.class, IdentityStoreHandler.class)
>
> If CDI would create that Bean<T> instance internally it would have
> DefaultIdentityStoreHandler.class among its types as well.
>
> With the exception of Interceptors (for which CDI has no SPI) the
> "regular" CDI bean ends up being identical to what you add as a Bean<T>,
> and then CDI doesn't know nor care whether the Bean<T> was added manually
> or was added via the scanning process.
>
>
>
>
>
>
>
>
>>
>> Best regards
>> Rudy
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Java EE Security API - JSR 375 - Experts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jsr375-experts+unsubscribe_at_googlegroups.com.
>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/jsr375-experts/CAL%2Bwt-5a3XzXXvY_eUP5rVyNL1cKN%2Bx6HKGA
>> %3DYz_aP-yMAx2yA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-5a3XzXXvY_eUP5rVyNL1cKN%2Bx6HKGA%3DYz_aP-yMAx2yA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>