Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartaee-tck-dev] I have a conflicting call this week on Wednesday + Persistence/GlassFish status...

I won't be able to attend the TCK call on Wednesday as I will be on another call. 

Regarding the Persistence application client tests, we still have a possible "lookup-name" workaround that we could apply to the Persistence tests that happen to use application client + EJB but there is no strong direction that seems best to follow as each "path for change" needs to be proven.

Switch from "ejb-link" to "lookup-name" option 1:

We could update https://github.com/jakartaee/platform-tck/blob/main/jpa/spec-tests/src/main/resources/com/sun/ts/tests/common/vehicle/appmanaged/appmanaged_vehicle_client.xml from:

<application-client xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="10" xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/application-client_10.xsd">
  <ejb-ref>
    <ejb-ref-name>ejb/AppManagedVehicleBean</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <remote>com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF</remote>
    <ejb-link>AppManagedVehicleBean</ejb-link>
  </ejb-ref>
</application-client>

To:

<application-client xmlns="https://jakarta.ee/xml/ns/jakartaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="10" xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/application-client_10.xsd">
  <ejb-ref>
    <ejb-ref-name>ejb/AppManagedVehicleBean</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <remote>com.sun.ts.tests.common.vehicle.appmanaged.AppManagedVehicleIF</remote>
    <lookup-name>java:global/jpa_core_EntityGraph_vehicles/jpa_core_EntityGraph_appmanaged_vehicle_ejb/AppManagedVehicleBean</lookup-name>
  </ejb-ref>
</application-client>

Pro: GlassFish 8 seems to just work with four of the tests modified to try the ^ change.  To follow up on that, we would need to try the same as a general change that hard codes the applicationclient.xml for each different test.

Con: Other implementations that previously just worked with the ejb-link approach may experience problems with the change to use lookup-name.  Both approaches are supported as per https://jakarta.ee/specifications/enterprise-beans/4.0/jakarta-enterprise-beans-spec-core-4.0#a4133

Reconsider how we run the Persistence tests on EE 11 implementations option 2:

Description of the application client tests do not even mention the "application client", pasting from https://github.com/jakartaee/platform-tck/blob/main/user_guides/platform/src/main/jbake/content/config.adoc that describe the four vehicles that we currently use with application client but not to test application client:

"
* `stateless3`: Bean-managed stateless session bean using JNDI to lookup
a Jakarta Transactions `EntityManager`; uses `UserTransaction` methods for transaction
demarcation

* `stateful3`: Container-managed stateful session bean using
`@PersistenceContext` annotation to inject Jakarta Transactions `EntityManager;` uses
container-managed transaction demarcation with a transaction attribute
(required)

* `appmanaged`: Container-managed stateful session bean using
`@PersistenceUnit` annotation to inject an `EntityManagerFactory`; the
`EntityManagerFactory` API is used to create an Application-Managed Jakarta Transactions
`EntityManager`, and uses the container to demarcate transactions

* `appmanagedNoTx`: Container-managed stateful session bean using
`@PersistenceUnit` annotation to inject an `EntityManagerFactory`; the
`EntityManagerFactory` API is used to create an Application-Managed
Resource Local `EntityManager`, and uses the `EntityTransaction` APIs to
control transactions
"

The option here would be to switch from application client to servlet.  This would be a big change I think but perhaps others think differently about it.

Stay on the current path option 3:

Eventually, we will find the test or GlassFish problem and fix it.  I'm thinking we could try running with a different EE 11 implementation to see if we see different results.

Scott

Back to the top