On Mon, Nov 5, 2018 at 4:36 PM Rick Ley <[email protected]> wrote: > > I tried working with StdDeserializer, and when I annotated the type in > question to use this custom deserializer, I got an exception saying there was > no default constructor. I tried extending JsonDeserializer instead, and was > able to get the deserialization working properly. Are there any pitfalls to > extending JsonDeserializer instead of StdDeserializer?
No, it's just slightly more work and there may be times when new methods are introduced (with no-op implementation in `JsonDeserializer`, but something more useful in `StdDeserializer`). So it may just be slightly more maintenance. Having said that, I am not sure I understand the exception problem there: missing exception would need to be on custom deserializer, so it seems difference would not be meaningful. Unless there is something expecting deserializers to be `java.io.Serializable` or something like that... in which case there might be something to change in `StdDeserializer`. -+ Tatu +- > > On Monday, November 5, 2018 at 1:50:49 PM UTC-8, Tatu Saloranta wrote: >> >> On Wed, Oct 31, 2018 at 12:25 PM Rick Ley <[email protected]> wrote: >> > >> > 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? >> >> Yes. >> >> Writing custom deserializers may be tricky with XML, but that is the >> useful base class here. >> >> -+ Tatu +- >> >> > >> > 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]> 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. > > -- > 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. -- 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.
