[
https://issues.apache.org/jira/browse/TOMEE-4650?focusedWorklogId=1031918&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031918
]
ASF GitHub Bot logged work on TOMEE-4650:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jul/26 18:54
Start Date: 23/Jul/26 18:54
Worklog Time Spent: 10m
Work Description: jungm opened a new pull request, #2847:
URL: https://github.com/apache/tomee/pull/2847
Fixes [TOMEE-4650](https://issues.apache.org/jira/browse/TOMEE-4650). Two
independent problems, both reproducing on Plume (EclipseLink) and the
webprofile distribution (OpenJPA) — so neither is a persistence-provider defect.
## 1. Undeploy closes an already-closed EntityManagerFactory
When a test (or application) closes a container-managed
`EntityManagerFactory` itself, TomEE's undeploy path called `close()` on it
again, and `Assembler.destroyApplication` then failed with *"Attempting to
execute an operation on a closed EntityManagerFactory"*. The test method
passed; only the undeploy step errored.
`ReloadableEntityManagerFactory.close()` now checks `isOpen()` before
delegating to the underlying EMF.
## 2. Missing Jakarta Persistence 3.2 CDI qualifier beans
TomEE did not register the CDI beans that the Jakarta EE 11 / Persistence
3.2 CDI integration requires for `persistence.xml`-declared units. Injecting a
qualified `EntityManagerFactory`, `EntityManager`, or `PersistenceUnitUtil`
(e.g. `@Inject @CtsEm2Qualifier`) failed at deploy time with
`UnsatisfiedResolutionException`.
A new `JpaCDIExtension` registers, for each persistence unit:
- `EntityManagerFactory` — `@ApplicationScoped`, bean name =
persistence-unit name
- `EntityManager` — in the scope given by `<scope>`, defaulting to
`jakarta.transaction.TransactionScoped`
- `CriteriaBuilder`, `PersistenceUnitUtil`, `Cache`, `SchemaManager`,
`Metamodel` — `@Dependent`, each obtained from the matching getter of the EMF
All of them carry the qualifiers declared by the `<qualifier>` elements, or
`@Default` when none is declared. The bean-registration contract (scopes,
qualifiers, bean name) was checked against the Jakarta EE 11 Platform spec
(`CDI-JPA`) and the Persistence 3.2 schema rather than from memory.
Supporting plumbing:
- `<qualifier>`/`<scope>` added to the `persistence.xml` JAXB model
(`PersistenceUnit`) in the XSD-mandated position. This model is
hand-maintained, not generated (the xjc profile does not cover persistence
schemas), and TomEE does not validate `persistence.xml` against a bundled XSD,
so no schema files needed updating.
- Fields carried through `PersistenceUnitInfo` and `AppInfoBuilder`, which
also honours the `jakarta.persistence.qualifiers` / `jakarta.persistence.scope`
override properties per the spec.
- Extension registered in `OptimizedLoaderService`, alongside the analogous
`ConcurrencyCDIExtension` it is modeled on.
## Tests
- `ReloadableEntityManagerFactoryCloseTest` — verifies a second `close()` is
a no-op. Confirmed it fails against the unpatched code (2 close calls instead
of 1).
- `JpaCDIExtensionTest` — verifies qualified and `@Default`
EMF/`PersistenceUnitUtil` injection across two persistence units. Confirmed it
fails against the unpatched code with the exact
`UnsatisfiedResolutionException` from the issue.
## Notes for reviewers
- The excluded TCK tests named in the issue
(`entityManagerFactoryCloseExceptions/ClientP{m,u}servletTest`,
`ee.cdi.ServletEMLookupTest`) live in the separate `apache/tomee-tck` harness
repo; their exclusion lines still need removing there once this merges. That
change is not in this PR.
- `SchemaManager`/`Metamodel`/`CriteriaBuilder`/`Cache` beans are registered
per spec but only `EntityManagerFactory` and `PersistenceUnitUtil` are
exercised in the unit tests — the others eagerly trigger OpenJPA entity
enhancement, which the unenhanced test setup in this module cannot satisfy. The
full validation is a TCK run.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1031918)
Remaining Estimate: 0h
Time Spent: 10m
> Undeploy closes an already-closed EntityManagerFactory; PU CDI qualifier
> beans missing
> --------------------------------------------------------------------------------------
>
> Key: TOMEE-4650
> URL: https://issues.apache.org/jira/browse/TOMEE-4650
> Project: TomEE
> Issue Type: Bug
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a test closes a container-managed {{EntityManagerFactory}} (EMF) itself,
> TomEE's undeploy path calls {{close()}} on it again.
> {{Assembler.destroyApplication}} then fails with "Attempting to execute an
> operation on a closed EntityManagerFactory". The test method itself passes;
> only the undeploy step after it errors. TomEE must check whether the EMF is
> already closed before calling {{close()}} on it during undeploy.
> Separately, TomEE does not register the CDI qualifier beans that Jakarta
> Persistence 3.2 requires for {{persistence.xml}}-declared units. When an app
> injects {{EntityManagerFactory}}, {{EntityManager}}, or
> {{PersistenceUnitUtil}} with a qualifier such as {{@CtsEm2Qualifier}},
> deployment fails with {{UnsatisfiedResolutionException}}. TomEE is missing
> this part of the Jakarta Persistence 3.2 CDI integration.
> Both problems show up on Plume (EclipseLink) and on the webprofile
> distribution (OpenJPA) alike, so neither is a persistence provider defect.
> h2. Steps to reproduce / TCK reference
> *
> {{ee.jakarta.tck.persistence.core.entityManagerFactoryCloseExceptions.ClientPmservletTest}}
> and {{ClientPuservletTest}} — excluded in
> {{runner-webprofile/exclusions/persistence-javatest.txt}} in the
> apache/tomee-tck harness repo. The {{exceptionsTest}} methods pass; the class
> reports an undeploy error.
> * {{ee.jakarta.tck.persistence.ee.cdi.ServletEMLookupTest}} — excluded in
> {{runner-webprofile/exclusions/persistence-servlet.txt}}. Deployment fails
> with {{UnsatisfiedResolutionException}} for {{@CtsEm2Qualifier}}.
> Remove the matching lines from both exclusion files once fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)