Initial draft of Jakarta Persistence/CDI EE integration tests

[starksm64]

This is a work in progress. The glassfish version in use does not seem to have a Jakarta Persistence integration that supports the custom qualifiers for injecting an EntityManager.

Fixes Issue
#1405

Related Issue(s)
Specify any related issue(s) links.

Describe the change
A clear and concise description of the change.

Additional context
Add any other context about the problem here.

CC @alwin-joseph @anajosep @arjantijms @cesarhernandezgt @dblevins @m0mus @edbratt @gurunrao @jansupol @jgallimore @kazumura @kwsutter @LanceAndersen @bhatpmk @RohitKumarJain @shighbar @gthoman @brideck @OndroMih @dmatej
@starksm64 @scottmarlow

[starksm64]

Glassfish issue for handling Jakarta Persistence 3.2 changes: eclipse-ee4j/glassfish#25198

[arjantijms]

@starksm64 some things I don't understand yet about this commit.

<persistence-unit name="CTS-EM" transaction-type="JTA">
    <description>Persistence Unit for CTS Vehicle Tests</description>
    <qualifier>ee.jakarta.tck.persistence.ee.cdi.CtsEmQualifier</qualifier>
    <jta-data-source>jdbc/DB1</jta-data-source>
    <class>ee.jakarta.tck.persistence.ee.entityManager.Order</class>
  </persistence-unit>

  <persistence-unit name="CTS-EM2" transaction-type="JTA">
    <description>Persistence Unit for CTS Vehicle Tests</description>
    <qualifier>ee.jakarta.tck.persistence.ee.cdi.CtsEmQualifier</qualifier>
    <jta-data-source>jdbc/DB1</jta-data-source>
    <class>ee.jakarta.tck.persistence.ee.entityManager.Order</class>
  </persistence-unit>

Both persistence units have the same qualifier. That doesn't seem to be allowed, as it will lead to ambigious candidates for injection.

Additionally, the spec uses cdi:scope here and cd:qualifier, but your example doesn't use that namespace:

https://github.com/jakartaee/platform/blob/main/specification/src/main/asciidoc/webprofile/jpa-cdi/CDI-JPA.adoc

[hantsy]

If Glassfish handled the persistence and CDI integration when switching to another persistence provider that provides the CDI integration, it will cause a conflict?

[arjantijms]

If Glassfish handled the persistence and CDI integration when switching to another persistence provider that provides the CDI integration, it will cause a conflict?

Basically, if that persistence provider included a CDI extension in its main jar / maven dependency. Although I don't think Hibernate will do this.

I think it's architecturally wrong for GlassFish to provide this. We also don't let GlassFish handle all the CDI concerns for Mojarra, Cocurro, or Soteria, just to name three.

But for EE 11 the ship has sailed, and we have to do it like this.

[scottmarlow]

<persistence-unit name="CTS-EM" transaction-type="JTA">
    <description>Persistence Unit for CTS Vehicle Tests</description>
    <qualifier>ee.jakarta.tck.persistence.ee.cdi.CtsEmQualifier</qualifier>
    <jta-data-source>jdbc/DB1</jta-data-source>
    <class>ee.jakarta.tck.persistence.ee.entityManager.Order</class>
  </persistence-unit>

  <persistence-unit name="CTS-EM2" transaction-type="JTA">
    <description>Persistence Unit for CTS Vehicle Tests</description>
    <qualifier>ee.jakarta.tck.persistence.ee.cdi.CtsEmQualifier</qualifier>
    <jta-data-source>jdbc/DB1</jta-data-source>
    <class>ee.jakarta.tck.persistence.ee.entityManager.Order</class>
  </persistence-unit>

Both persistence units have the same qualifier. That doesn't seem to be allowed, as it will lead to ambigious candidates for injection.

^ appears to be resolved now as the qualifier for CTS-EM2 was updated.

[arjantijms]

^ appears to be resolved now as the qualifier for CTS-EM2 was updated.

Indeed, I updated it myself. Unfortunately I never heard back from @starksm64 about this.

[arjantijms]

The conflicts are resolved, and GlassFish 8.0.0-SNAPSHOT passes the test. There's still open questions, and we have to add more tests, but let's do these in followup PRs.