9:47 a.m.
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).
Our work in progress implementation of ^ is being tracked via WFLY-19554
<https://issues.redhat.com/browse/WFLY-19554> [2] + pull request
<https://github.com/wildfly/wildfly/pull/19088> [3].
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
but if we remove support for duplicate persistence unit definitions in
WildFly what would be the implication of that? Some possible answers as to
what the impact would be if WildFly either failed to deploy applications
with duplicate persistence unit definitions or ignored some duplicate
copies of the same persistence unit definitions will be in a response to
this email.
Another question that came up is should WildFly use a separate BeanManager
instance per module/submodule? I think that it is valid for WildFly to use
a global BeanManager instance as mentioned in [5].
So how can we address the failure without removing the EntityManagerFactory
bean name?
Could we use a more unique bean name that combines the containing module
name (e.g. ear/war/jar name) + the persistence unit name?
Could we contain a persistence unit hint to avoid adding the persistence
unit name to the EntityManagerFactory name?
Do you have other ideas? Or feedback on ^?
Thanks!
Scott
[1]
https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0#...
[2] https://issues.redhat.com/browse/WFLY-19554
[3] https://github.com/wildfly/wildfly/pull/19088
[4]
https://github.com/wildfly/wildfly/pull/19088/files#diff-9d21579f8a3180d3...
[5] https://struberg.wordpress.com/2015/02/18/cdi-in-ears