Update handling of persistence units for Jakarta Persistence 3.2

[starksm64]

Environment Details

• GlassFish Version (and build number): 8.x
• JDK version: 17+
• OS: any
• Database: any

---

Problem Description

Jakarta Persistence 3.2 has added qualifier and scope annotations for supporting injection of an EntityManager. The current glassfish 8.x branches still only support the Jakarta Persistence persistence_3_0.xsd schema.

Steps to reproduce

This draft PR on the platform-tck has an example of injecting an EntityManager using a custom qualifier specified in the deployment persistence.xml:
jakartaee/platform-tck#1623

Running that test fails because the injection site is not recognized as equivalent to one with the commented out @PersistenceUnit(unitName = "CTS-EM") annotation.

@RequestScoped
public class TestBeanEM {
    Logger logger = Logger.getLogger(TestBeanEM.class.getName());

    //@PersistenceUnit(unitName = "CTS-EM")
    @CtsEmQualifier
    @Inject
    private EntityManager em1;

The current deployment failure is:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type EntityManager with qualifiers @CtsEmQualifier
  at injection point [BackedAnnotatedField] @CtsEmQualifier @Inject private ee.jakarta.tck.persistence.ee.cdi.TestBeanEM.em1
  at ee.jakarta.tck.persistence.ee.cdi.TestBeanEM.em1(TestBeanEM.java:0)

	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:379)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:294)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:141)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:534)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:65)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:63)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
]]

Impact of Issue

Glassfish will not be able to pass the EE 11 platform tck until this is resolved.

[starksm64]

@arjantijms

In looking at the glassfish codebase, the PersistenceContext injection is handled by the com.sun.enterprise.deployment.annotation.handlers.EntityManagerReferenceHandler class, as well as org.glassfish.weld.services.InjectionServicesImpl.

I don't see any easy way to add an alias from an annotation to the PersistenceContext annotation. Maybe an annotation processor could be used to bootstrap the initial ratifying release. It would rewrite the custom qualifier annotation from the persistence.xml to the correct PersistenceContext with the same persistence-unit the qualifier was specified in.

Alternatively, it would seem a synthetic bean for EntityManagerReferenceHandler that replaces the @AnnotationHandlerFor(PersistenceContext.class) type with a @AnnotationHandlerFor(qualifier.class) could be used.

Any other thoughts on where to add this processing?

[hantsy]

Not sure if this is related to eclipse-ee4j/eclipselink#2207

[OndroMih]

Yes, @hantsy, this issue replaces eclipse-ee4j/eclipselink#2207. It’s really a responsibility of GlassFish as Jakarta EE container, to provide the producer. EclipseLink just provides the info about the qualifier class that matches the persistence unit.