-
-
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
Unresolved forward reference from seemingly valid json #235
Comments
I am guessing that the problem may be that properties are fed via constructor parameters -- and this prevents binding of id of the container, before deserializing its contents. |
@cowtowncoder I think I just ran into this limitation. I've got:
and Jackson fails to deserialize with: Where line 5, column 17 refers to I want to require this as a constructor argument to ensure the Object is well-formed. Moving the logic into a setter would potentially allow bad objects to get constructed.
|
You should try using 2.4.X: resolution of forward reference was revamped and I think it is now supported. |
@pgelinas I am seeing this problem on 2.4.3. |
Odd. In theory this should be fixed by 2.4.4 using #610. I upgraded to 2.4.4 but I still get the error. Any ideas? |
Ok, OP from 2013 indicated 2.2.2; I had to be sure about version used ;) In this case, it might be related to constructor params, I'd have to check. Constructor params have a special kind of treatment, so it might be that forward reference isn't properly handled for creator properties. I quickly skimmed the code and I think there is indeed something missing. Unfortunately, I'm not in an environment where I can test and debug this right now. |
@pgelinas Something is funky, to be sure. I am not able to reproduce the problem in a minimal testcase (meaning, forward references work there) so I am slowly adding more and more detail from my real application to see when it breaks. |
@pgelinas Ah ha! Got it. This bug only occurs if the constructor contains: |
I am guessing it probably invokes different code path; deserializer has a few distinct paths, some involving more optimized handling, others for buffering, and this can result in incomplete handling for some features. |
Filed a second bug related to resolved forward-references: #658 |
I think the new bugs cover the new problem, and it's better to close this one since it has bit different history (i.e. there are multiple underlying problems). |
Using the attached JSON file, Jackson 2.2.2, and the following code, I see the error:
544068 is a top level object that is later referenced in an array in a child (I've also attached a screenshot that makes this easier to see). The id field appears early in the data, just after the _type field) and before any children objects. This seems like it should be valid, and we have client side code that parses it using a map. This seems simliar to issue 97 but the presence of the id field early in the data seems to distinguish it.
The text was updated successfully, but these errors were encountered: