-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Exception while deserializing with @JsonRootName #2253
Comments
Correct: it is expected there is exactly one root-level property to match. Feature is most commonly used with XML content (and basically was added for compatibility with XML-to-json processing libraries like Jettison) where there can only be one root-level element. So this works as expected. I am open to suggestions for better documentation if that would help. |
So what would be suggested a way to handle the above scenario? Write a class which would wrap the outer node? Also, yes we can give some examples and add a note stating the same in the documentation. Basically emphasizing on when it would work and when it wouldn't. What do you think? |
Also looking for help with this. Any suggestions? The standard API call has the correct root element, but apparently some of our clients are also sending other metadata top-level fields. We can safely ignore them, but the root unwrapping is throwing MismatchedInputException. |
It feels like FAIL_ON_TRAILING_TOKENS should ignore this? The default is false, but it still throws the exception. |
I guess it would not work is what @cowtowncoder told. @cowtowncoder can you give an example or redirect us to one if it exists already? This would help us a lot! Thanks a ton in advance. |
I don't think I think I would suggest this is invalid usage, partly since JSON logical model does not guarantee ordering, and unwrap functionality does not deal with that. But I think I would be interested in finding a solution for specific use case. It is probably possible to model in a way that works. But a non-trivial problem is that Lombok seems to be used which limits workarounds a bit. |
What about a non-Lombok use case? Could there just be a new DeserializationFeature? Like IGNORE_EXTRA_ROOT_ELEMENTS or something? The unwrap functionality should already know the desired root element name from the annotation. |
I am bit wary of either changing definitions of features involved, or adding a single-use feature. I will have to think more about handling here: a significant part of hesitation is the fact that I don't know how involved it would be to allow original code to work as shown, for both XML and JSON cases. I'll tag this as 2.10 since behavioral change is involved. |
@efenderbosch The feature request makes sense as this would have lots of usecases in JSON. @cowtowncoder The same could be applicable for XML as well, wouldn't it?
|
@pritibiyani No, not really, XML and JSON are NOT identical structurally: there is impedance regarding names. So, following might represent identical logical content: { "x" : 1, "y" : 2 } <point>
<x>1</x>
</y>2<y>
</point> and so any "root name" in case of XML must be for The original reason to support { "point" : {
"x" : 1,
"y" : 2
}} which is redundant and clumsy, but is easier to convert to/from xml. |
Perhaps there is chance to improve the documentation. Also, is there any way we could only provide this for JSON? Do we have any other use cases, where we need to implement certain functionality only for XML and/or JSON? |
Maybe just another method could be added to |
In the meantime, @pritibiyani you can try something like this: https://gist.github.com/efenderbosch/36354b0abc1083d63f70c44687e1cafb |
Although addition of a method in @pritibiyani Question on format-specific annotations is interesting one -- I have occasionally thought about this as it does seem like there are cases where optional inclusion would make sense (only include on X, or exclude from Y). This could possibly be doable with some sort of wrapper/container annotation, although would need to enumerate what annotations would be allowed within. Alternative possibility, for same goal, could be to allow |
I'm not sure the problem's been solved. Let me share what I did. <point>
<x>1</x>
</y>2<y>
</point> {
"point" : {
"x" : 1,
"y" : 2
}
} I'm not allowed @XmlRootElement
class AbstractType<SELF extends AbstractType<SELF>> {
@JsonIgnore
@XmlTransient
public SELF get() { // should be used for getting the result.
if (wrapped != null) {
return wrapped;
}
return this;
}
@XmlTransient
@Setter
@Getter
private SELF wrapped;
}
class Point extends AbstractType<Point> {
@JsonProperty("point")
public Point getWrapped() {
return super.getWrapped();
}
} Above class deserialise both following JSON. {
"point" : {
"x" : 1,
"y" : 2
}
} {
"x" : 1,
"y" : 2
} |
Desirialization does not work when there are multiple nodes available at same level as value provided in the JsonRootName
Note:
Wrapper is configured with following:
Class:
Input JSON (which works):
Input JSON (which does not work)
The text was updated successfully, but these errors were encountered: