Cxf dev2

[prathyushreddylpr]

Description

Fixed the flaky tests named testDeserialization inside SerializationTest.java and AttributeTest.java classes.

cxf/rt/javascript/javascript-tests/src/test/java/org/apache/cxf/javascript/types/SerializationTest.java

Line 91 in 3048785

public void testDeserialization() throws Exception {

cxf/rt/javascript/javascript-tests/src/test/java/org/apache/cxf/javascript/types/AttributeTest.java

Line 73 in 3048785

public void testDeserialization() throws Exception {

Root Cause

The test testDeserialization has been reported as flaky when run with the NonDex tool. The tests failed because of the serialization of Testbean and AttributeTestBean classes, where the order of elements in the serialized XML changes between runs. The contents of the serialized strings do not remain constant and hence the tests are failing.

Fix

To define a specific order for the XML elements when the classes TestBean1 and AttributeTestBean are serialized, we need to add the propOrder attribute to the @XmlType annotation. This attribute explicitly specifies the order in which fields should be serialized.

How this has been tested?

Java: openjdk version "11.0.20.1"
Maven: Apache Maven 3.6.3

1. Module build - Successful
   Command used -

mvn install -pl core -am -DskipTests

2. Regular test - Successful
   Command used -

mvn -pl rt/javascript/javascript-tests test -Dtest=org.apache.cxf.javascript.types.SerializationTest#testDeserialization

mvn -pl rt/javascript/javascript-tests test -Dtest=org.apache.cxf.javascript.types.AttributeTest#testDeserialization

3. NonDex test - Failed
   Command used -

mvn -pl rt/javascript/javascript-tests edu.illinois:nondex-maven-plugin:2.1.7-SNAPSHOT:nondex -Dtest=org.apache.cxf.javascript.types.SerializationTest#testDeserialization

mvn -pl rt/javascript/javascript-tests edu.illinois:nondex-maven-plugin:2.1.7-SNAPSHOT:nondex -Dtest=org.apache.cxf.javascript.types.AttributeTest#testDeserialization -DnondexRuns=10

NonDex test passed after the fix.

[reta]

@prathyushreddylpr I don't see any comparison logic in org.apache.cxf.javascript.types.SerializationTest.testDeserialization that relies on order of the properties. where this hypothesis is coming from?

[prathyushreddylpr]

@prathyushreddylpr I don't see any comparison logic in org.apache.cxf.javascript.types.SerializationTest.testDeserialization that relies on order of the properties. where this hypothesis is coming from?

In the 'testDeserialization' there is a call to 'rhinoCallInContext' which internally calls deserializeTestBean3_1(serialized string) here: '

cxf/rt/javascript/javascript-tests/src/test/resources/deserializationTests.js

Line 33 in 74069a1

function deserializeTestBean3_1(xmlString)

' and the actual comparison is happening here.

[reta]

@prathyushreddylpr I don't see any comparison logic in org.apache.cxf.javascript.types.SerializationTest.testDeserialization that relies on order of the properties. where this hypothesis is coming from?

In the 'testDeserialization' there is a call to 'rhinoCallInContext' which internally calls deserializeTestBean3_1(serialized string) here: '

https://github.com/apache/cxf/blob/74069a140737603a0a59435de308401c4351a80b/rt/javascript/javascript-tests/src
' and the actual comparison is happening here.

But it compares deserialized form of each attribute, the order does not matter here

[prathyushreddylpr]

@prathyushreddylpr I don't see any comparison logic in org.apache.cxf.javascript.types.SerializationTest.testDeserialization that relies on order of the properties. where this hypothesis is coming from?

In the 'testDeserialization' there is a call to 'rhinoCallInContext' which internally calls deserializeTestBean3_1(serialized string) here: '
https://github.com/apache/cxf/blob/74069a140737603a0a59435de308401c4351a80b/rt/javascript/javascript-tests/src
' and the actual comparison is happening here.

But it compares deserialized form of each attribute, the order does not matter here

Yes but when the class is serialized to a string, the attributes does not follow any particular and when the string is compared with certain value it is causing the issue. For example, below are two serialized strings for two different runs:
First:

Second:

[reta]

Yes but when the class is serialized to a string, the attributes does not follow any particular and when the string is compared with certain value it is causing the issue. For example, below are two serialized strings for two different runs:

Could you please point out where this serialized string is compared to another serialized strings? I have found none such places, and the order does not matter here as far as all attributes have the same values.

[prathyushreddylpr]

Yes but when the class is serialized to a string, the attributes does not follow any particular and when the string is compared with certain value it is causing the issue. For example, below are two serialized strings for two different runs:

Could you please point out where this serialized string is compared to another serialized strings? I have found none such places, and the order does not matter here as far as all attributes have the same values.

The comparison is happening here:

cxf/rt/javascript/javascript-tests/src/test/resources/deserializationTests.js

Line 33 in 74069a1

function deserializeTestBean3_1(xmlString)

In the above code bean.getStringItem is expecting "bean1>stringItem". But serialized string contains two string items(example is provided in the above comment) and one of them contained the value "required=true" and hence the order is important

[reta]

But serialized string contains two string items(example is provided in the above comment) and one of them contained the value "required=true" and hence the order is important

I don't see two items, I see (from your examples):

and

The other two string items belong to beanTwoItem which is nested serialized bean

[prathyushreddylpr]

But serialized string contains two string items(example is provided in the above comment) and one of them contained the value "required=true" and hence the order is important

I don't see two items, I see (from your examples):

and

The other two string items belong to beanTwoItem which is nested serialized bean

Sorry for the confusion, I have debugged the issue further and understood that the issue is not with the serializing of the string but with the parsing of the 'xmlString' here:

cxf/rt/javascript/javascript-tests/src/test/resources/deserializationTests.js

Line 35 in 74069a1

var dom = parseXml(xmlString);

I observed that sometimes when the string is converted to XML, the attributes' values become null(see screenshot below), and defining propOrder will trigger a more consistent marshaling behavior within JAXB. When propOrder is defined, JAXB takes additional steps to ensure all properties are accounted for and processed systematically, which it might not do when relying on the default (implicit) order.

[reta]

When propOrder is defined, JAXB takes additional steps to ensure all properties are accounted for and processed systematically, which it might not do when relying on the default (implicit) order.

Thanks @prathyushreddylpr , I am very surprised by your findings but if that is indeed the case, this definitely not a CXF but JAXB implementation issue (we use Glassfish one), could you please report it there?

[prathyushreddylpr]

Glassfish

@reta , can you please let me know how I can report this to JAXB? Is this:https://github.com/eclipse-ee4j/glassfish the glassfish repo that you mentioned?

[reta]

@reta , can you please let me know how I can report this to JAXB? Is this:https://github.com/eclipse-ee4j/glassfish the glassfish repo that you mentioned?

@prathyushreddylpr I suppose you could open an issue there with the test case that demonstrates the problem with JAXB implementation (you may need to craft the reproducer without Apache CXF context since as per your explanation, it is purely dictated by JAXB with propOrder setting).