Hi Markus, Great news!
Personally I'd keep the small wiring we have right now and implement jsonb3 flavor aside since both have different design and dont converge so no need to make it complicated. Le ven. 7 avr. 2023 à 22:57, Jean-Louis MONTEIRO <jeano...@gmail.com> a écrit : > Hi Markus, > > I'll have a look from Monday on. Thanks for jumping into this and helping > out. > > Note that if we have to break something to pass the TCK now is the good > time. > > We are already breaking backward compatibility because of javax to Jakarta > namespace. So I don't have any problem. > > Best regards > > Le ven. 7 avr. 2023, 16:46, Markus Jung <m...@markus-jung.dev> a écrit : > > > Hi all, > > > > I’m currently working on implementing JSON-B 3 polymorphism. See > > https://github.com/jungm/johnzon/tree/jsonb3-polymorphism, still WIP as > I > > need to write tests + documentation and remove johnzon-jsonb-extras. But > > it’s passing all TCK polymorphism tests except for one as of right now > (And > > that last one is probably related to locale validation in johnzon). > > > > I couldn’t really implement this on top of the current way polymorphism > > works in johnzon-mapper because it expects that JSONs will always only > > contain one property to describe it’s type vs the JSON-B 3 spec having > > multiple properties to describe the type. > > As of now I have created a default polymorphism implementation that > > seamlessly mimics the way polymorphism used to work before in > > johnzon-mapper to avoid breaking changes for users, but this approach > > creates some redundancies in MapperBuilder. > > > > Ideally I’d like to completely remove this old polymorphism code also > from > > MapperBuilder and create some sort of PolymorphismBuilder that could be > > used instead and plugged into MapperBuilder. But this will obviously > break > > the API for anyone using johonzon-mapper directly with polymorphism. Any > > thoughts on this? > > > > > > Thanks > > > > Markus >
