Per the current TCK Process documentation, please find bellow a challenge related to JSON-B TCK. Can someone please add the challenge label which is required by the TCK Process but not available to everyone to add.
The relevant specification version and section number(s)
Only following test in the class are related to the challenge
testCreatorDeserialization
The exact TCK version
JSON-B TCK version 3.0.0
The implementation being tested, including name and company
Apache Johnzon 2.0.0-SNAPSHOT from the Apache Software Foundation
A full description of why the test is invalid and what the correct behavior is believed to be
The test aims at covering the polymorphic mapping using JsonbTypeInfo and JsonbSubtype which is fine. The DateConstructor, in its current form
public static final class DateConstructor implements SomeDateType {
public LocalDate localDate;
@JsonbCreator
public DateConstructor(@JsonbProperty("localDate") @JsonbDateFormat(value = "dd-MM-yyyy", locale = "nl-NL") LocalDate localDate) {
this.localDate = localDate;
}
}
There is an ambiguity there in the way the localDate field should be deserialized. We have 2 candidates
the factory (constructor from DateConstruct)
the setter (direct field access which is public without a private setter)
The test implies that only one, the DateConstructor constructor and not the direct field.
In Johnzon we call first the factory and then the setters, because we see them as callback for the user to use after the object is constructed.
In this situation, the specification does not provide with a clear order. I'm going to create a issue to clarify this point but meanwhile, we need a challenge for this test.
I propose to create a PR in order to change the localDate modifier from public to private so there is no ambiguty anymore. We can add a public getter so we can even write an assert in the test using the deserialized value.
Per the current TCK Process documentation, please find bellow a challenge related to JSON-B TCK. Can someone please add the
challengelabel which is required by the TCK Process but not available to everyone to add.The relevant specification version and section number(s)
https://jakarta.ee/specifications/jsonb/3.0/jakarta-jsonb-spec-3.0.html#custom-instantiation
The coordinates of the challenged test(s)
Only following test in the class are related to the challenge
testCreatorDeserialization
The exact TCK version
JSON-B TCK version 3.0.0
The implementation being tested, including name and company
Apache Johnzon 2.0.0-SNAPSHOT from the Apache Software Foundation
A full description of why the test is invalid and what the correct behavior is believed to be
The test aims at covering the polymorphic mapping using JsonbTypeInfo and JsonbSubtype which is fine. The DateConstructor, in its current form
There is an ambiguity there in the way the localDate field should be deserialized. We have 2 candidates
The test implies that only one, the DateConstructor constructor and not the direct field.
In Johnzon we call first the factory and then the setters, because we see them as callback for the user to use after the object is constructed.
In this situation, the specification does not provide with a clear order. I'm going to create a issue to clarify this point but meanwhile, we need a challenge for this test.
I propose to create a PR in order to change the localDate modifier from public to private so there is no ambiguty anymore. We can add a public getter so we can even write an assert in the test using the deserialized value.