11:17 a.m.
On Tue, Aug 5, 2025 at 9:59 AM Scott Marlow <
scott.marlow.opensource(a)gmail.com> wrote:
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
Why do we allow it? You're right that we do, so we need to deal with that
fact, but for the sake of context why do we do this? Was there some
important use case it allows that is otherwise unachievable?
My guess is this was a matter of being forgiving. Perhaps being forgiving
of the TCK, if it includes a lot of deployments like this.
Do we all agree this kind of deployment is an anti-pattern?
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.
What does allowing this mean for the existing JNDI-based injection? If a PU
is defined in both an ear/lib and in ear/war1, but say, not in ear/war2,
what happens?
If we fail deployments with duplicate PU definitions, what does that mean
for the TCK? I assume if the current situation results in 10925 failures,
failing the deployment would as well. We'd just be changing how the
deployment fails.
Can ignoring some duplicate copies be restricted to this CDI use case? IOW
if there is some JNDI injection scenario that works now but would not work
if we started ignoring duplicates, can we just ignore the duplicate for CDI
injection?
For example the PU is defined in ear/lib and in ear/war1, but not in
ear/war2. But war2 uses the PU via JNDI injection.
If we did that, would the TCK pass? Or is this a case of the TCK assuming
somehow vendors make deployments set up this way work. That sounds like a
TCK challenge unless there's spec language that clearly requires it to work.
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].
This would be a major change in how WF works and almost certainly would
break people somehow. Perhaps something to consider for a year or more from
now, if we think this would be better in general, but going down this path
for this particular situation seems like the last resort.
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
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His