-
-
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
Invalid index error when deserializing unwrapped list element with multiple attributes #101
Comments
updated test case to add in serializeTest also, which works. |
Thank you for reporting this. |
I'm also finding that when I set my POJO to use all JAXB annotations:
And run the above tests, I get a very strange result:
Instead of the expected:
It appears as if my JAXB annotations are completely being ignored. Reading #6 and http://blog.bdoughan.com/2012/12/jaxb-representing-null-and-empty.html I figured the default behavior for Lists should be "unwrapped" for JAXB annotations. I've also tried using Jackson annotations with:
But that would give me the original invalid index error. |
On part of defaulting: Jackson does not necessarily use JAXB defaults -- it is not a JAXB implementation; it can use JAXB annotations as input, but otherwise there are some discrepancies. As to JAXB annotations being ignored: have you enabled support for JAXB annotations? XML module does not use them automatically (similar to JSON support). |
Ok I can reproduce this issue with given test. Thanks! |
Thanks cowtowncoder, I tried debugging this and I can see where the issue is. After jackson finished looping through the valid attributes in the List elements, it continue to call getAttributeLocalName() on the non-List element "name" which has a attributeCount of 0. If I place the non-List element before the List element, then this problem is solved. But with large amounts of auto-generated POJOs sometime it's not so easy to control the ordering :) |
Yes, the problem is related to attributeCount not being cleared to match actual number of attributes. That much I could see by bit of debugging. The question then is where is this assignment missing... |
I came across this issue as well and have a one line fix if you happen to be building from source rather than an archive. When XmlTokenStream#_initStartElement() is called on an element that is not part of the current collection it assumes that the collection has ended implicitly. When this happens it returns the XML_END_ELEMENT token id and doesn't pull the new attribute count from the _xmlReader. Move There hasn't been much traction on this issue in a couple months, so I wasn't certain if it had already been fixed internally. If you'd like me to submit a pull request I'd be happy to. |
Thanks! I can check this out locally and merge if all unit tests pass. |
Excellent, thank you @escholz! I fixed this in master and 2.3 (for 2.3.3 release); all tests pass, including ones that were failing for this one earlier. |
Great! Glad I could help. |
This issue was originally pointed out by https://github.com/ShijunK in #64
I also came across this issue while working with a very complex XML and thought it would be worthwhile raising this on its own. I've re-used ShijunK's example:
The exception is:
I'm using Jackson 2.3.1 with Woodstox 4.2.0. I will attempt to work around this issue by using JAXB in the meanwhile.
The text was updated successfully, but these errors were encountered: