attempt to respecify dataSource

[gavinking]

Refinement of what was stated in #423 to reflect what we're actually doing with this in practice. Basically, say that the dataSource can just be the name of a persistence unit.

[otaviojava]

@njr-11 could you review this one?

[njr-11]

I remembered why I didn't write this with the PersistenceUnit name in the first place.
I'm not aware of an API or SPI that Jakarta Persistence provides to do this given the name of a persistence unit:

     * then the container-managed {@code EntityManagerFactory} for that
     * persistence unit is used, obtained as if it had been injected using the
     * {@code PersistenceUnit} annotation.

The closest I see is Persistence.createEntityManagerFactory(persistenceUnitName), but that is only for Java SE and also not container managed. It's also possible that there is something in Jakarta Persistence that I am overlooking.

I would also be fine with including some language for Java SE usage here.

[gavinking]

@PersistenceContext and @PersistenceUnit both inject based on the unit name.

[gavinking]

I mean, the Javadoc is super-confusing:

    /**
     * (Optional) The name of the persistence unit as defined
     * in the {@code persistence.xml} file. If specified, the
     * persistence unit for the entity manager factory that is
     * accessible in JNDI must have the same name.
     */

I don't know what that second sentence means. But I'm basing my assertion on the first sentence:

The name of the persistence unit as defined in the persistence.xml file

[njr-11]

@PersistenceContext and @PersistenceUnit both inject based on the unit name.

Right, but we have written the Data spec not to require a compile time step that generates code. I think we would need an equivalent to Persistence.createEntityManagerFactory(persistenceUnitName) for Jakarta EE usage to ensure it is always implementable.

[arjantijms]

I think we would need an equivalent to Persistence.createEntityManagerFactory(persistenceUnitName) for Jakarta EE usage to ensure it is always implementable.

+1