Implementing Generic Beans with CDI / Weld

I just came from my tiny pretty world of JavaSE / Guice and am currently discovering the container-portable path -EE6. After some problems with Glassfish3.1, I just switched to JBoss and now run into a problem that shouldn't be like that.

As an infrastructure support class, I am trying to create a common / DAO repository for any type of entity. Very simple, it may look like this.

public class Repository<E, K extends Serializable & Comparable<K>> { private final Instance<EntityManager> entityManagerInstance; protected final Class<E> getDomainObjectClass() { return domainObjectClass; } private final Class<E> domainObjectClass; protected final EntityManager getEntityManager() { return entityManagerInstance.get(); } @Inject public Repository(Instance<EntityManager> entityManageryProvider, Provider<E> domainObjectProvider) { //This is a dirty hack, sadly :( domainObjectClass = (Class<E>)domainObjectProvider.get().getClass(); this.entityManagerInstance = entityManageryProvider; } public final void persist(E domainObject) { final EntityManager em = getEntityManager(); em.persist(domainObject); } public final Collection<E> getAllEntities() { final EntityManager em = getEntityManager(); final CriteriaBuilder cb = em.getCriteriaBuilder(); final CriteriaQuery<E> query = cb.createQuery(getDomainObjectClass()); final List<E> result = em.createQuery(query).getResultList(); return Collections.unmodifiableList(result); } public final E find(K id) { Preconditions.checkNotNull(id); final EntityManager em = getEntityManager(); return em.find(getDomainObjectClass(), id); } // [...] } 

Now there may be a bean that does not require entity-specific capabilities, but simply a repository of a certain type of entity, for example (it can be a test one):

 public class DomainObjectARepositoryTest{ @Inject Repository<DomainObjectA, PersistableUUID> domainObjectARepository; @Test public void testMitarbeitererstellung() { for (DomainObjectA a : domainObjectARepository.getAllEntities()) { // do cool stuff } } } 

Unfortunatly Weld does not seem to like this generic injection. During deployment, I get the following error:

 state=Create: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Repository<DomainObjectA , PersistableUUID>] with qualifiers [@Default] at injection point [[field] @Inject sompackage.DomainObjectARepositoryTest.domainObjectARepository] 

Am I missing something or just forgot to introduce a generic injection? As far as I understand the general material, it is still erased after compilation, even until now it was so good in guice3.

Yours faithfully,

Avi

edit: found comment garvin king that this behavior is in the specification but not implemented in welding (staement was in June 2009)

+7
source share
1 answer

This is more of a long comment than a complete answer to your question, but may point you in the right direction:

I have been following the discussions in seam-dev and the welder for quite some time, and I don’t remember that something like this appeared. Therefore, I assume that this has not been on the agenda since Gavin commented on this.

That you can relatively easily check this assumption:

(a) Get a link to the BeanManager and request it for the appropriate bean type (or just for Object to save on the save side), of course, you will have to remove @Inject in DomainObjectARepositoryTest to start the application.

(b) Register the extension and listen to ProcessBean for what appears during deployment. This would be my proposed method, you will find more information here .

With this result, you can probably find out if there are bean types Repository<E, K extends Serializable & Comparable<K>>

It would be great if you would report the results here and also consider giving the Jira problem in a negative case.

+1
source

All Articles