Hello,
The Jakarta EE 11 Platform implementations must include built-integration of Jakarta Persistence with the CDI bean manager [1], allowing injection of a container-managed entity manager factory using the annotation jakarta.inject.Inject. Also expected is support for injecting EntityManager/CriteriaBuilder/PersistenceUnitUti/Cache/SchemaManager/Metamodel as well. Note that SchemaManager can only be injected on WildFly Preview since that is a new api included in Jakarta Persistence 3.2.
This is a really nice feature as it allows applications to rely more on CDI for injection of persistence units/contexts (and other contained Persistence types). Injecting the EntityManagerFactory is typically used for application managed persistence contexts (e.g. EntityManager) where the application deals with closing the EntityManager instance when it wants to. An application managed persistence context is almost the same thing as extended persistence contexts except the Persistence container does not manage it and application managed persistence contexts can also be used in most EE components where as extended persistence contexts are limited to use in Stateful Beans. Injecting an EntityManager bean is equivalent to accessing a transaction scoped entity manager (e.g. @PersistenceContext EntityManager myentitymanager).
List of WildFly test failures with this change:
1. org.jboss.as.test.integration.jpa.packaging.PersistenceUnitPackagingTestCase fails with:
"Cannot deploy scopedToEar.ear...
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name mainPu resolves to beans: [Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: Object, EntityManagerFactory, AutoCloseable, qualifiers: @Any @Default], Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: Object, EntityManagerFactory, AutoCloseable, qualifiers: @Any @Default]]"}}}}
"
2. org.jboss.as.test.integration.jpa.initializeinorder.InitializeInOrderTestCase fails with similar ear test failure caused by:
"WELD-001414: Bean name is ambiguous. Name pu1 resolves to beans: [Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: EntityManagerFactory, Object, AutoCloseable, qualifiers: @Any @Default], Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: EntityManagerFactory, Object, AutoCloseable, qualifiers: @Any @Default], Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: EntityManagerFactory, Object, AutoCloseable, qualifiers: @Any @Default]]"}
"
3. org.jboss.as.test.integration.jpa.packaging.PersistenceUnitWarPackagingTestCase falis with similar ear test failure caused by:
"Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name mainPu resolves to beans: [Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: EntityManagerFactory, Object, AutoCloseable, qualifiers: @Any @Default], Configurator Bean [interface jakarta.persistence.EntityManagerFactory, types: EntityManagerFactory, Object, AutoCloseable, qualifiers: @Any @Default]]"}}}}
"
4. The Jakarta EE 10 Platform TCK also has similar failures in 10925 Persistence tests when run with the current [3] change with WildFly.
Why are we getting test failures and how to address the failures?
[4] contains the EntityManagerFactory bean setup method that uses the application supplied persistence unit name to name the EntityManagerFactory bean. If we comment out the call to "beanConfigurator.name(persistenceUnitMetadata.getPersistenceUnitName())" the WELD-001414 error goes away. We aren't supposed to comment that line of code out as per the [1] requirements which mention we need to set the (EntityManagerFactory) "bean name given by the name of the persistence unit".
I believe that we are getting the WELD-001414 error in EAR deployments that contain duplicate persistence unit definitions (e.g. ear/lib contains a jar with the same persistence.xml as is also contained in subdeployments). Gavin King asked me a good question as to why WildFly is allowing duplicate persistence unit definitions in application deployments. A fair question