Thank you for your response. Given that information, we are investigating the possibility of writing a custom deserializer for this type. To get me started, it looks like we should be extending StdDeserializer<Item>? Is that correct?
On Tuesday, October 30, 2018 at 8:04:45 PM UTC-7, Tatu Saloranta wrote: > > On Tue, Oct 30, 2018 at 7:26 PM Rick Ley <[email protected] <javascript:>> > wrote: > > > > Hello! > > > > We are working on client libraries for a service. One of the service > APIs can return an xml list with heterogeneous types ordered by name. There > are two possible types in this list. A sample response might be: > > > > <Items> > > <TypeA> > > <Name1> > > </TypeA> > > <TypeB> > > <Name2> > > </TypeB> > > <TypeA> > > <Name3> > > </TypeA> > > <TypeA> > > <Name4> > > </TypeA> > > <TypeB> > > <Name5> > > </TypeB> > > <TypeB> > > <Name6> > > </TypeB> > > <TypeA> > > <Name7> > > </TypeA> > > <TypeB> > > <Name8> > > </TypeB> > > <TypeB> > > <Name9> > > </TypeB> > > </Item> > > > > The goal is to deserialize this list into two separate lists that each > hold all of one of the types. So with the given example, we would hope to > see (with the Name here being shorthand for a fully deserialized object): > listOfTypeA={Name1, Name3, Name4, Name7} and listOfTypeB = {Name2, Name5, > Name6, Name8, Name9}. Instead, we are seeing listOfTypeA = {Name7} and > listOfTypeB={Name8, Name9}. In other words, only the last contiguous set of > names is persisted and returned. > > > > I have stepped through the code and confirmed that this is because each > time an element of a certain type is encountered, a new list is created and > eventually overwrites any other list that was previously on the root object > rather than appending to an existing list. More specifically, each time > CollectionDeserializer.deserialize is called, a new list is instantiated. > > > > Our object model is the parent type of name Item, which has an > ArrayList<TypeA> and ArrayList<TypeB>. Each is annoted with @JsonProperty() > and the respective type name. We are using Jackson version 2.8.11. > > > > Is there a way we can configure Jackson to yield the behavior we want? > Or some sort of workaround you can suggest? Or should I make a feature > request/issue on the repo? > > > > Thank you for your help! > > To give a simple answer, no, Jackson can not be configured to do that. > I also do not see this as something that would be possible to support > in suggested form. > > Problem is two-fold: > > 1. Polymorphic type handling: it might be possible to make work, but > lack of wrapping for list would present a problem. > 2. Splitting of contents of one logical container at data format level > into 2 Java Collections: this is not supported for any format. > > If (1) was resolved (that is, you could get one List populated, from > polymorphic types), (2) could probably be handled by defining setter > method that takes list, and then splitting that up in code. > > -+ Tatu +- > -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
