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 <[email protected]> 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 <[email protected]>: > > > > 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 <[email protected] > >: > >> > >> 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 > >> > > > >
