XML configuration of JpaIdentityStoreConfiguration

[jonne.deprez]

Hi,

I've noticed that in JpaIdentityStore the method

public Collection<IdentityObject> findIdentityObject(
            IdentityStoreInvocationContext ctx,
            IdentityObjectType identityType, IdentityObjectSearchCriteria searchCriteria)
            throws IdentityException {
...
}

does not take the searchCriteria argument into account. This is a pity, because this makes it impossible to search for users by the value of an attribute (first name, last name, ...).

I tried to extend the JpaIdentityStore class and inject that class into JpaIdentityStoreConfiguration using the beans.xml, but to my surprise the class is never modified, whatever I try. For some reason it is impossible to modify the JpaIdentityStoreConfiguration.

<picketlink:JpaIdentityStoreConfiguration>

        <s:modifies/>

        <picketlink:identityStoreClass>com.grantsnap.admin.ExtJpaIdentityStore</picketlink:identityStoreClass>

</picketlink:JpaIdentityStoreConfiguration>

Weird, because the modification to for example MailConfig of seam-mail is picked up. Could this related to the fact that JpaIdentityStoreConfiguration is a CDI extension, while MailConfig is not?

Could someone explain me how to modify JpaIdentityStoreConfiguration using beans.xml or how to extend JpaIdentityStore?

I'm deploying on JBossAS 7.0.2 and using Seam 3.1.0.Final.

Thanks!

[lightguard]

Have you tried using an @Alternative or perhaps @Specializes?

[jonne.deprez]

Yes I have, and it didn't work. I added Specializes and Alternative annotations to a class that extends the JpaIdentityStoreConfiguration bean and activated the alternative in beans.xml, but my class is not used by Seam Security.

My application is built with maven and packaged as a war. The dependencies from the pom are included as jars in the WEB-INF/lib directory, and they include the seam-security libraries.

Do beans in one such a jar (such as JpaIdentityStoreConfiguration and the beans of Seam Security that have this bean injected) only "see" the context of their own jar or can they inject beans from other archives, such as my war? Or said differently: is their just one BeanManager for the war, or does each archive inside the war have its own BeanManager?

[lightguard]

How about @Default from Solder? If that doesn't do it, I'm really not sure what would.

[jonne.deprez]

I suppose you meant @DefaultBean from Solder. If I understand correctly this annotation is meant to be used by bean developers that want to allow other developers to easily override the default implementation. If another bean is available it will be used, otherwise the CDI falls back to the bean annotated with @DefaultBean. JpaIdentityStoreConfiguration was not annotated like this by the author, so I don't think it will help.

I'm still unable to modify this bean to replace JpaIdentityStore by my own implementation. However, at startup of JBoss 7 the bean is mentioned by the XmlConfigExtension:

16:31:21,112 INFO  [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-3) Adding XML Defined Bean: org.jboss.seam.security.management.picketlink.JpaIdentityStoreConfiguration

But later the modified values are not injected into the bean, while it is the case for that other bean that I modify with Solder XML, i.e. MailConfig:

16:31:22,267 INFO  [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-3) Wrapping InjectionTarget to set field values: org.jboss.seam.mail.core.MailConfig

So I started to debug XmlConfigExtension and noticed that for JpaIdentityStoreConfiguration CDI never throws a ProcessInjectionTarget event and it is exactly the observer for this event that later modifies the bean.

Could this be because JpaIdentityStoreConfiguration implements the javax.enterprise.inject.spi.Extension interface and that such classes are not considered as managed beans?

Is it possible to modify a bean that implements javax.enterprise.inject.spi.Extension?

[lightguard]

I've asked Shane to give a more detailed response, hopefully he is able to respond quickly.

[jonne.deprez]

Any reaction from Shane?

[shane.bryzak]

Oops, sorry I missed this post earlier.  It seems you're right about JpaIdentityStoreConfiguration - because it is an extension, it can't be configured via XML.  You can probably work around this by creating your own configuration bean with identityClass, credentialClass, etc properties, then after application startup set these values in JpaIdentityStoreConfiguration yourself.