[jackson-user] Serialization of any object with parent-child relationships without outputing the ID value
If I have to serialize an object that I can not annotate and that contains parent-child relationship, such as a *DefaultMutableTreeNode*, I can avoid the infinite recursion/stack overflow problem by supplying an *ObjectIdGenerator *from the *findObjectIdInfo*() method in a subclass of the *JacksonAnnotationIntrospector. *The ID value is in the resulting JSON object. There's an example here: http://stackoverflow.com/questions/27316485/using-jsonidentityinfo-without-annotations (In addition, with the *DefaultMutableTreeNode *class I have to supply a custom *BeanPropertyWriter *to handle exceptions thrown when serializing objects like this. See: http://stackoverflow.com/questions/35359430/how-to-make-jackson-ignore-properties-if-the-getters-throw-exceptions/35416682) I have 3 constraints I'm trying to satisfy: 1. I can not annotate objects in various dependent libraries. 2. I can not enumerate ahead-of-time all of the possible objects that have parent-child relationships 3. I do not want the virtual ID value from an ObjectIdGenerator in the serialized JSON object, although I still need a way to keep track of them. To satisfy 1 and 2 I was thinking of using an ObjectIdGenerator for all objects, regardless of whether they contain parent-child relationships or whether I had access to the source files. This would simplify development, but are there performance penalties for doing this? I'm not sure how to proceed with #3. What objects do I need to sub-class in order to get this to work? It looks like the actual output is done by the *WritableObjectId *object, which is returned from the *DefaultSerializerProvider.findObjectId()* method. But the *WritableObjectId *is declared final so I can't override its *writeAsField()* method. Is there another way to do this? Thanks for your help. -- This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.emdgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. -- 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 jackson-user+unsubscr...@googlegroups.com. To post to this group, send email to jackson-user@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[jackson-user] Re: Android - Problem deserialising JSON to object in 'release' builds
Turns out the problem was due to the class I was using to deserialise my JSON was declared within my activity class, therefore an inner class. I read that inner classes can be used with the Jackson ObjectMapper as long as they were declared static which this was, so not exactly sure why it didn't work in 'release' mode. As soon as I moved it to become a regular public class it all worked fine. On Friday, 10 February 2017 18:26:08 UTC, Jonathan Wareham wrote: > > Hi, > > I'm using Jackson in my Android app to parse JSON returned from a REST > API. Most of it works fine other than a couple of places where I'm > using ObjectMapper.readValue and ObjectMapper.treeToValue to convert JSON > to objects. It works fine every time when running the 'debug' build > variant, but when running the 'release' build the object fails to get > created and the method just returns null. > > I've read a lot about ensuring Proguard settings are configured correctly, > but I'm not using Proguard and have removed all related settings. Is there > anything else that could be causing the issue in 'release' builds? > > Thanks, > Jonathan > -- 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 jackson-user+unsubscr...@googlegroups.com. To post to this group, send email to jackson-user@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [jackson-user] Serialization of any object with parent-child relationships without outputing the ID value
On Thu, Feb 16, 2017 at 1:43 PM, David Hayek wrote: > If I have to serialize an object that I can not annotate and that contains > parent-child relationship, such as a DefaultMutableTreeNode, I can avoid the > infinite recursion/stack overflow problem by supplying an ObjectIdGenerator > from the findObjectIdInfo() method in a subclass of the > JacksonAnnotationIntrospector. The ID value is in the resulting JSON object. > > There's an example here: > http://stackoverflow.com/questions/27316485/using-jsonidentityinfo-without-annotations > > (In addition, with the DefaultMutableTreeNode class I have to supply a > custom BeanPropertyWriter to handle exceptions thrown when serializing > objects like this. See: > http://stackoverflow.com/questions/35359430/how-to-make-jackson-ignore-properties-if-the-getters-throw-exceptions/35416682) > > I have 3 constraints I'm trying to satisfy: > > 1. I can not annotate objects in various dependent libraries. > 2. I can not enumerate ahead-of-time all of the possible objects that have > parent-child relationships > 3. I do not want the virtual ID value from an ObjectIdGenerator in the > serialized JSON object, although I still need a way to keep track of them. How would the id be known on deserialization then, if it is not written as part of data? Is it calculated from other fields? > To satisfy 1 and 2 I was thinking of using an ObjectIdGenerator for all > objects, regardless of whether they contain parent-child relationships or > whether I had access to the source files. This would simplify development, > but are there performance penalties for doing this? > > I'm not sure how to proceed with #3. What objects do I need to sub-class in > order to get this to work? It looks like the actual output is done by the > WritableObjectId object, which is returned from the > DefaultSerializerProvider.findObjectId() method. But the WritableObjectId is > declared final so I can't override its writeAsField() method. Is there > another way to do this? Current system is designed for Object Id to be included in data, so even if sub-classing was allowed, changing behavior in sub-class would be a fragile solution. I am not necessarily against removing `final` keyword, but just suggesting that it might be better to add explicit support which could (and should) be tested via unit tests, to avoid accidental breakages. So I guess I would be open to improvement ideas that would achieve this with less work than many overrides; but also if you want, please file an RFE for just making `WritableObjectId` non-final. Ideally this should go in 2.9, but I think this is one of cases where change in patch would be acceptable (reverse of making method final would not be -- but this change can not break anything wrt code that worked with earlier patches). -+ Tatu +- > > Thanks for your help. > > > > This message and any attachment are confidential and may be privileged or > otherwise protected from disclosure. If you are not the intended recipient, > you must not copy this message or attachment or disclose the contents to any > other person. If you have received this transmission in error, please notify > the sender immediately and delete the message and any attachment from your > system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not > accept liability for any omissions or errors in this message which may arise > as a result of E-Mail-transmission or for damages resulting from any > unauthorized changes of the content of this message and any attachment > thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not > guarantee that this message is free of viruses and does not accept liability > for any damages caused by any virus transmitted therewith. > > Click http://www.emdgroup.com/disclaimer to access the German, French, > Spanish and Portuguese versions of this disclaimer. > > -- > 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 jackson-user+unsubscr...@googlegroups.com. > To post to this group, send email to jackson-user@googlegroups.com. > 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 jackson-user+unsubscr...@googlegroups.com. To post to this group, send email to jackson-user@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
