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/
> msgid/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.
>