Support @Inject EntityManager

[hantsy]

JPA 3.2 should support injecting an EntityManager or EntityManagerFactory by @Inject.

I created a simple example to verify it but found it did not work as expected.

The testing env is:

• Java 21
• Glassfish 8.0.0 M6 with built-in EclipseLink 5.0.0 B02

Add scope and qualifier in the persistence.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="3.2" xmlns="https://jakarta.ee/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_2.xsd">
    <persistence-unit name="defaultPU" transaction-type="JTA">
        <qualifier>com.example.employee.MyCustom</qualifier>
        <scope>jakarta.enterprise.context.ApplicationScoped</scope>
....

I tried to inject it with the custom qualifier like this.

@ApplicationScoped
public class EmployeeRepository {

    @Inject
    @MyCustom
    EntityManager entityManager;

    public List<Employee> allEmployees() {
        return entityManager.createQuery("select p from Employee p", Employee.class)
                .getResultList();
    }
}

And I got the following exception:

Unsatisfied dependencies for type EntityManager with qualifiers @MyCustom
  at injection point [BackedAnnotatedField] @Inject @MyCustom com.example.employee.EmployeeRepository.entityManager
  at com.example.employee.EmployeeRepository.entityManager(EmployeeRepository.java:0)

[hantsy]

The issue is still existed Glassfish 8.0.0-M8/EclipseLink 5.0.0-B03, https://github.com/hantsy/jakartaee11-sandbox/actions/runs/11928004837/job/33244279869

[rfelcman]

Sorry but could You point me to the Jakarta Persistence Specification 3.2 https://jakarta.ee/specifications/persistence/3.2/jakarta-persistence-spec-3.2 where is @Inject mentioned? I know only about @PersistenceContext jakarta.persistence.PersistenceContext annotation only.

[hantsy]

Check jakartaee/persistence#377

[hantsy]

https://in.relation.to/2024/04/01/jakarta-persistence-3/

The persistence.xml file now has and elements supporting the use of CDI to inject an EntityManager or EntityManagerFactory.
In fact, these elements aren’t limited to use with CDI, they can be used with any implementation of jakarta.inject.

[hantsy]

jakartaee/persistence@2840bd8

[rfelcman]

But I think, that this issue should be targeted to Java EE container which handle injection @Inject. In this case Glassfish.
Unsatisfied dependencies ... exception text comes from Glassfish.

[hantsy]

I do not know.

If it is related to Glassfish etc. Please transfer this issue to Glassfish.

[hantsy]

But I think, that this issue should be targeted to Java EE container which handle injection @Inject. In this case Glassfish. Unsatisfied dependencies ... exception text comes from Glassfish.

See my persistence XML file changes in 3.2, I added scope and qualifer there, when running in a Jakarta EE container, it should provider a EntityManager and EntityManagerFactory bean in the context.

[OndroMih]

This is being addeessed in this GlassFish issue: eclipse-ee4j/glassfish#25198. This issue can be closed.

[arjantijms]

I do have to add that I think this really should be a concern of EclipseLink ultimately.

This becomes more clear in the case of Piranha, which is a highly modular runtime that basically just assembles components. Each component uses the EE APIs to integrate themselves. The runtime should have no specific knowledge of any of the components being assembled.

We're not there today, but we should aim for this.

[hantsy]

EclipseLink could add a cdi module to integrate CDI/Jakarta EE.

[OndroMih]

I agree that EclipseLink could have an extension to integrate with CDI. We could raise a new issue as a feature request.

What do you think, @rfelcman, @lukasj ?

[rfelcman]

From my point of view no. It should be duty of JEE servers.

[arjantijms]

Jakarta Transactions (the implementations of it) also contain their own code for providing CDI functionality.

Jakarta Faces likewise.

It's just like in old Java ee versions, the container had to integrate Jax-rs and JSF etc, but by using ServletContainerInitializer implementations could integrate themselves.

CDI extensions are what ServletContainerInitializers are for Servlet.

Using extensions a component can integrate itself. No need for the container to do that.

[OndroMih]

@rfelcman

From my point of view no. It should be duty of JEE servers.

What I meant is to have an optional module in Eclipselink to provide a CDI extension. Similar to other optional modules, like moxy, json, nosql.

Jakarta EE servers could enable it and use it out of the box, or could provide their own mechanism. Having an extension in Eclipselink would also allow users of plain EclipseLink to add this extension to add the built-in producers to their application if they also use CDI. The usecase is not only for app servers.