Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] [glassfish-dev] @Version field support seems to be ignored by EclipseLink during Jakarta EE 11 Platform TCK testing...
I thought more about this case and it seems like the EclipseLink way might be different than others (that always start with initial value of 0) but starting the Version counter with a null value as the initial value that when incremented then goes to a value of zero seems okay as EclipseLink counters represented this way will be able to have one additional increment value (null, 0, ..., max short or whatever max of the type is).

Unless I hear otherwise, I think we should update the EE 11 Platform TCK tests to allow the initial version of null which will require some changes but should be okay

Thoughts?.

Scott

On Thu, Apr 10, 2025 at 1:50 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

@Entity
@Table(name = "A_BASIC")
@Access(AccessType.FIELD)
public class ShortClass_Field implements java.io.Serializable {

// ===========================================================
// instance variables

@Id
protected String id;

@Version
protected Short basicShort;
...
public Short getVersion() {
return this.basicShort;
}

public void setVersion(Short value) {
this.basicShort = value;
}
...

Scott

On Thu, Apr 10, 2025 at 1:29 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
Removed GlassFishml as the Jakarta EE 11 Platform TCK is seeing behaviour that looks like a possible EclipseLink bug.  I will create a tracking issue for this. 

Description:

The Platform TCK is running the following code in a JTA transaction:

getEntityManager().persist(new ShortClass_Field("3"));
ShortClass_Field a = getEntityManager().find(ShortClass_Field.class, "3");
ShortClass_Field a = getEntityManager().find(ShortClass_Field.class, "3");
log.info("shortFieldTest, a="+a);
if (a != null) {
    logTrace( "version:" + a.getVersion());
    // if (a.getVersion() == 1) {
    Short version = a.getVersion();
    log.info("shortFieldTest, a.version="+version);
    a.setName("two");
    getEntityTransaction().begin();
    getEntityManager().merge(a);
    getEntityManager().flush();
    getEntityTransaction().commit();
    ShortClass_Field a1 = getEntityManager().find(ShortClass_Field.class, "3");
    log.info("shortFieldTest, a1="+a1);
    if (a1 != null) {
       if (a1.getVersion() > version) {

In the above code a + a1 objects are:

a = {ee.jakarta.tck.persistence.core.annotations.version.ShortClass_Field} "ShortClass_Field[id: 3, version: null, name: null]"
 id = "3"
 basicShort = null
 name = null
 _persistence_primaryKey = "3"
 _persistence_cacheKey = null
 _persistence_listener = null
 _persistence_fetchGroup = null
 _persistence_shouldRefreshFetchGroup = false
 _persistence_session = null
a1 = {ee.jakarta.tck.persistence.core.annotations.version.ShortClass_Field@14253} "ShortClass_Field[id: 3, version: 1, name: two]"
 id = "3"
 basicShort = {java.lang.Short@14333} 1
  value = 1
 name = "two"
 _persistence_primaryKey = "3"
 _persistence_cacheKey = null
 _persistence_listener = {org.eclipse.persistence.internal.descriptors.changetracking.AttributeChangeListener@14334} "AttributeChangeListener(null)"
 _persistence_fetchGroup = null
 _persistence_shouldRefreshFetchGroup = false
 _persistence_session = null

The last line of code is "a1.getVersion() > version" which will throw an exception since the "version" is null.

How can we get EclipseLink to assign value 0 when the ShortClass_Field is first persisted?

This failing test used to specify an initial value for version fields but changed for Jakarta EE 11 due to accepted challenge https://github.com/jakartaee/persistence/issues/637 to leave the version field as null since the Persistence Provider is expected to set the value of the @Version field.

Thoughts?

Scott



On Wed, Apr 9, 2025 at 3:09 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On Wed, Apr 9, 2025 at 3:02 PM Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:
Hi,

Yes indeed. The entire 8.0 branch could (should) be merged into 8.0-JDK17 again. I just haven't found the time for it yet,

Meanwhile, the persistence TCK should work with JDK 21 as well, so maybe it's an option to use JDK 21 in the meantime?

Good point, https://ci.eclipse.org/jakartaee-tck/job/11/job/tck/job/jpa-test/21 was run with Java 21 and also fails the same Version Annotation tests which likely means that the described feature doesn't work as documented (I believe).  We will need a new EclipseLink issue I think for the described case.

Scott


Kind regards,
Arjan Tijms


On Wed, 9 Apr 2025 at 20:54, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
It looks like https://github.com/eclipse-ee4j/glassfish/blob/8.0/appserver/pom.xml#L117 already has  `<eclipselink.version>5.0.0-B07</eclipselink.version>`, so could that be merged to the 8.0-JDK1 branch as well?

On Wed, Apr 9, 2025 at 2:40 PM Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:
Hi,

Unfortunately that doesn't help so much.

The problem is that the main branch for GlassFish 8 is "8.0". That is where we make all the changes, and then only for some releases we merge 8.0 into the 8.0-JDK17 branch.

Commits are of course highly appreciated, but they have to go into the 8.0 branch first. Otherwise we get merge issues down the line (we tried this before and it didn't work uit well).

Kind regards,
Arjan Tijms








On Wed, 9 Apr 2025 at 20:35, Scott Marlow via glassfish-dev <glassfish-dev@xxxxxxxxxxx> wrote:
Just created https://github.com/eclipse-ee4j/glassfish/pull/25447 for updating GlassFish to use the latest EclipseLink 5.0.0-B07 release in case that helps.

Scott

On Wed, Apr 9, 2025 at 2:06 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On Wed, Apr 9, 2025 at 1:58 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
From debugging a Jakarta EE 11 Platform TCK test failure it looks like @Version support might not be in the EclipseLink version included in glassfish-8.0.0-M11.zip.  The tracking issue for the failure is currently platform-tck/issues/2112 [1].  I pushed an EE 11 Platform TCK change to [2] to help with reproducing the test failure.

Does EclipseLink include support for the Version Annotation?  It looks like the EclipseLink master branch had recent Version related changes for eclipselink/issues/2343 [3] but I'm not sure if that change is in glassfish-8.0.0-M11.zip yet.

The entity with the @Version is [4]:
"
@Entity
@Table(name = "A_BASIC")
@Access(AccessType.FIELD)
public class ShortClass_Field implements java.io.Serializable {

	// ===========================================================
	// instance variables

	@Id
	protected String id;

	@Version
	protected Short basicShort;
...
"

Note that in EE 10 the Platform TCK test manually set the basicShort property values but in response to TCK challenge 2112 [1], the code is changed to require the Persistence Provider to set the version field.  Do we need an EclipseLink tracking issue for adding EclipseLink support for automatically setting the version field?

Sorry, the accepted TCK challenge issue is https://github.com/jakartaee/persistence/issues/637

Please do advise if EclipseLink can add support for @Version properties such as shown above.

Scott
 





_______________________________________________

glassfish-dev mailing list

glassfish-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev







































  Back to the top