Afaiu it's the other way around: When the JSON gets scanned the JsonParser passed to the JsonbDeserializer is directly at the position of the attribute. But Yassoon seems to skip further to the array already as they expect a START_ARRAY. I would need to test Yassoon with the sample json I created.
The type is imo rather clear from the corresponding Java class which it should map to. LieGrue, strub > Am 19.09.2023 um 15:13 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 >>>> >>> >> >>
