Hi JL, thanks for looking at it! The part with JSON itself is from the RFC, but the behaviour of the JsonbDeserializer is from the JSON-B specification. But whit this area is somewhat underspecified it just makes no sense to have these 2 almost identical situations behave different. I'll have a talk with Dmitry to check how to proceed.
LieGrue, strub > Am 19.09.2023 um 19:50 schrieb Jean-Louis Monteiro <jlmonte...@tomitribe.com>: > > @Mark I don't think it's going to be accepted as is > > From https://jakarta.ee/committees/specification/tckprocess/ > >> Challenges MUST be filed via the specification project’s issue tracker >> using the label challenge and include the following information: >> >> - >> >> The relevant specification version and section number(s) >> - >> >> The coordinates of the challenged test(s) >> - >> >> The exact TCK version >> - >> >> The implementation being tested, including name and company >> - >> >> A full description of why the test is invalid and what the correct >> behavior is believed to be >> - >> >> Any supporting material; debug logs, test output, test logs, run >> scripts, etc. >> >> If there is the same test and it behaves differently from CDI env to Java > SE env, it's probably an issue. > The problem with this spec is that there is no spec, it mostly refers or > uses the RFC as reference. > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Tue, Sep 19, 2023 at 3:14 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> Hi Mark, >> >> Guess the main issue is that our impl assumes/constrains about the >> structure whereas the spec enables to map any type to any type. >> We have some hacks to try to find by heuristic the right type but it does >> not always work so maybe something to improve. >> >> Main issue we had was the history on that feature, we didnt take the spec >> path at all pre-spec time. >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>> >> >> >> Le mar. 19 sept. 2023 à 16:21, Mark Struberg <strub...@yahoo.de.invalid> a >> écrit : >> >>> I've now created a github issue. >>> https://github.com/jakartaee/jsonb-api/issues/344 >>> >>> Jean-Louis, you are more experienced in this area: is this the correct >> way >>> to file a TCK challenge for JSON-B? >>> >>> txs and LieGrue, >>> strub >>> >>>> Am 19.09.2023 um 13:56 schrieb Mark Struberg <strub...@yahoo.de>: >>>> >>>> This gets even wilder as the non-CDI TCK test has the correct >> behaviour: >>>> >>>> >>>> >>> >> https://github.com/jakartaee/jsonb-api/blob/master/tck/src/main/java/ee/jakarta/tck/json/bind/customizedmapping/serializers/model/serializer/AnimalListDeserializer.java#L40 >>>> >>>> >>>> So the JSON-B TCK test for native deserialisers assumes different >>> behaviour than the TCK test for deserialisers which use CDI? Should not >> be >>> imo! >>>> >>>> LieGrue, >>>> strub >>>> >>>>> Am 19.09.2023 um 13:42 schrieb Mark Struberg >> <strub...@yahoo.de.INVALID >>>> : >>>>> >>>>> hi! >>>>> >>>>> Trying to work on the few TCK tests which still fail in Johnzon. >>>>> >>>>> Does anyone understand why the following deserializer is expecting to >>> see a START_OBJECT of the actual items instead of the actual current >>> JsonValue event which is a START_ARRAY? >>>>> >>>>> >>> >> https://github.com/jakartaee/jsonb-api/blob/master/tck/src/main/java/ee/jakarta/tck/json/bind/cdi/customizedmapping/serializers/model/serializer/AnimalListDeserializerInjected.java#L44 >>>>> >>>>> >>>>> The value to parse is >>>>> { "animals" : [ { "type" : "cat", "cuddly" : true, "age" : 5, "furry" >> : >>> true, "name" : "Garfield" , "weight" : 10.5}, { "type" : "dog", >> "barking" : >>> true, "age" : 3, "furry" : false, "name" : "Milo", "weight" : 5.5}, { >>> "type" : "animal", "age" : 6, "furry" : false, "name" : "Tweety", >> "weight" >>> : 0.5} ] } >>>>> >>>>> This is from the TCK test >>> >> ee.jakarta.tck.json.bind.cdi.customizedmapping.serializers.SerializersCustomizationCDITest >>>>> >>>>> My problem is that a List<X> or X[] in Java can be represented as json >>> object which is more complicated, e.g. >>>>> >>>>> { >>>>> "animals": >>>>> { >>>>> "size":3, >>>>> "values": [ { "type" : "cat", "cuddly" : true, "age" : 5, "furry" >>> : true, "name" : "Garfield" , "weight" : 10.5}, { "type" : "dog", >> "barking" >>> : true, "age" : 3, "furry" : false, "name" : "Milo", "weight" : 5.5}, { >>> "type" : "animal", "age" : 6, "furry" : false, "name" : "Tweety", >> "weight" >>> : 0.5} ] >>>>> } >>>>> } >>>>> >>>>> I don't see how the approach implemented by Yasson will allow to >>> deserialise such a JSON string. >>>>> >>>>> Or do I miss something? >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>> >>> >>> >>
