-
-
Notifications
You must be signed in to change notification settings - Fork 221
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
Deserialization with XmlMapper and DeserializationFeature.UNWRAP_ROOT_VALUE no longer works in 2.12 #485
Comments
Looks like the linked-to repository does not exist any more? |
Apologies, the repo was private. Could you please try it now? |
Same problem here. We just updated our libraries to 2.12.5, and one of them uses the XML mapper. It looks like the |
@ionel-sirbu-crunch yes, I can access that. @marcospassos This is not a bug but feature, as per #374: due to the way XML works, the outermost element is effectively ignored regardless of this settings. That ticket explains rationale. If this is due to #374, it would not be considered a bug, but fix to inconsistent/wrong behavior. It is unfortunate if there is existing code that counted on that behavior, however. |
Yes, but it's a breaking change, isn't it? |
Jacksons simply can't deserialize anything anymore, so all properties are null now. |
This was not known to be a use case; no tests covering it. Unless I misunderstand usage, it was not supported to begin with -- and was confusing for users since serialization and deserialization for XML were asymmetric: things simply would not work if you serialized something, then tried to read it back. This was not reported as an issue during Jackson 2.12 release candidate phase, as far as I know, meaning that 2.12.0 was released with the change as intended. But if and when it turns out there is existing usage I do want to figure out how to resolve that, for 2.13. 2.12 is something we can do little about because its API is fixed (no additions) and since behavior of .0 was changed purposefully. I am a little bit hesitant to try to undo change and allow Regardless I really want to resolve this for 2.13.0. Perhaps I do need to undo the change. |
We'll try to adjust on our side to not bring more maintenance for something that isn't officially supported. So, for us, no need to spend time on this. |
@marcospassos I appreciate your flexibility and am sorry there was this breakage. I will still consider revert here; I simply did not realize the feature was used (and considered useful) on XML side. |
@cowtowncoder Thanks for looking into this! As I mentioned in the initial description, we only deserialize the XML data (it comes from an external service), so I wasn't aware of the asymmetry of the Should you decide to leave this feature as it is, may I suggest adding a matrix of unsupported Many thanks! |
@ionel-sirbu-crunch I fully agree! And yes, I can see why in deserialize-only case this functionality can be useful (although as per original issue, there may be quirks with some content). Looking at code change(s) involved, I think I can do a revert here. Just wondering it there should be another switch for XML module to (optionally) just ignore that setting altogether. Regardless, I think the idea of mentioning complications for |
Created #494 for possible follow-up work. |
I've recently updated a project at work to Spring-boot 2.5.2 & one of the tests started failing. As it turns out, the root cause lies in the deserialisation of XML data.
We use the root unwrapping feature & have the data model class annotated with
@JsonRootName
.I've created a very simple project to give you an example of our usage here.
Old, working version: 2.11.4
New, non-working version: 2.12.3
Any advice is much appreciated.
Thanks!
The text was updated successfully, but these errors were encountered: