Opposite implementation of @JsonUnwrapped

[hemantvsn]

Serializing object of the following class yeilds string like

public class User implements Serializable{

private Integer id;
private String name;
private Integer pinCode;
private String city;

// getters /setters

}

{"id":1,"name":"XYZ","pinCode":123456,"city":"ABC"} But we want that attributes pinCode and city should be a part of new Json node say address node.

So my expectation of the result is:

{ "id": 1, "name": "XYZ", "address": { "pinCode": 123456, "city": "ABC" } } Can this be accomplished without re-organizing the class structure and by using Json annotations

on the exact opposite lines of @JsonUnwrapped

http://stackoverflow.com/questions/37724834/jackson-serialize-and-wrap-attributes-into-a-new-object

[cowtowncoder]

Did you check existing issues before filing new one? It seems to me that #42 is what you want.

[hemantvsn]

Yeah...its same as 42 Closing it Thanks

[andredasilvapinto]

Since #42 is locked and github hasn't added "something better than needing to add more +1 comments" during the last year: 👍

[cowtowncoder]

@andredasilvapinto :)

Rest assured that I understand how highly wished this item is. +1 for github adding something, anything, to help with priorization wishes -- those are valuable, but right now lead to noise.

[mjustin]

Rest assured that I understand how highly wished this item is. +1 for github adding something, anything, to help with priorization wishes -- those are valuable, but right now lead to noise.

https://github.com/FasterXML/jackson-annotations/issues/42#issuecomment-178032034

Enough voting -- locking issue for now, hoping github will add something better than needing to add more +1 comments. :)

Isn't this exactly what GitHub reactions (added 3/10/2016 — after the comment on #42 but before the above comment on this issue) are often used for?

[andredasilvapinto]

Not sure, as those can be also added for comments, are not exclusive for voting and might get easily lost or be unnoticed to the maintainers. Github needs first class voting support that can be easily tracked, not just emojis.

[mjustin]

@andredasilvapinto Let me restate. I've personally seen multiple projects use GitHub reactions for this purpose. For instance, I've seen multiple situations where the project owner has asked people to stop posting "+1" comments and instead use the GitHub reactions to vote for the item.

That said, I completely agree that this usage has its own issues, including the reasons you brought up, as well as the issue with people posting comments in projects that prefer the usage of GitHub reactions.

[andredasilvapinto]

@mjustin Let's hope GitHub comes up with a better feature for this use case that not only reduces noise, but is also easily trackable and assures reporters that the maintainers are aware of their continued interest in the feature/bug. Till then, let's use what we have.

[cowtowncoder]

I'll unlock the other issue hoping users will add reactions -- it works well enough for "voting" purpose here, and I'll delete +1s if any.

[andredasilvapinto]

@cowtowncoder out of curiosity, how do you plan on tracking the number of reactions? going through the issues every now and then? I see there are not many open ones in this specific project, so it might work, but that is a manually intensive task which wouldn't really scale for repositories with multi-hundred open issues (like others in this org).

[cowtowncoder]

@andredasilvapinto I don't track it regularly, but I sometimes go through lists of open issues. It's not a prime signal in general, but sort of "better than nothing", and is something users can do to indicate their preference.