-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preventing infinite recursion caused by circular references #29
Comments
Thanks for your suggestion, I will try to include this or something similar in 1.8.0 which I will be released around mid-oct. |
Any progress with this issue? Is there some solution to handle cyclic reference and avoid stack overflow (other than remove one side of bidirectional reference)? Thanks! |
Is there some update about that? |
Sorry I've been super busy and lost track of this. I'll think about something based on what @lalpert suggested and will reply back here before the end of the week with a timeline. |
Would it work if I create an annotation to override the type adapter of a particular field in a class? For example public class Person {
private int id;
private String name;
private House house;
}
public class House {
@TypeAdapter(SimplePersonAdapter.class)
private Person owner;
}
public class SimplePersonAdapter implements TypeAdapter<Person> {
//this class just serializes a simplified version of a Person object, for example it could just serialize the id
} |
@interappcci, @lalpert I think I will include my suggestion in my previous comment since it solves also a different requirement that was raised to me the other day. Does that work for both of you in regards to the circular reference problem? |
I just need to cxclude a field at the second nested while serializing a object:
|
Jackson has a solution to serializing classes with bidirection references using
@JsonIdentityInfo
(For example, see http://www.baeldung.com/jackson-bidirectional-relationships-and-infinite-recursion#json-identity-info). This way, you can serialize either object, and rather than causing a stack overflow error, it will just include a reference back to the object already included in the serialization.It seems like Gson does not have a solution like that. Could that be added to gson-fire?
The text was updated successfully, but these errors were encountered: