-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Exceptions when deserialize Setterless properties with type info(polymorphic deserialization) #501
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
Comments
Ok. I assume that if you added actual setter for Thank you for reporting this. |
Yes. When there's actual setter or the getter is corresponding to the field name behind(that's, getAlist() instead of getList()), it works just fine. And I had a temporary workaround fork here: https://github.com/fangzhen/jackson-databind/commit/deb02f0313691c8fe176584f6178e126ca2b4111, But it changed API of |
Yeah, there should be no need to change the api here, nor assume that type information comes from an array -- it's not related to inclusion of values, but for inclusion of type id. |
I'm not quite clear of the relation of valueDeserializer and typeDeserializer. So I just tried to follow what
At my point of view, I think that the first is for deserializing normal cases without type info and setterless properties, the second is for those with setterless properties and the third for type info. But we dont have one for those both with type info and setterless properties. And similarly, the And the third one in CollectionDeserializer are impled as:
And I just followed it... But I think it happens to work since currently deserializeTypedFromXXX method are the same. The test case should reproduce the problem for version 2.4.0. Please let me know if it didn't. |
@fangzhen understood, relationship is not trivial to understand; and API may well be missing things since earlier versions did not handle as many things as newer ones (i.e. API not designed to pass more information than what was needed at a time). Wrt methods: second method does not exist to support setterless properties, but for Anyway: I did not mean to criticize your approach, but just try to help understand original design idea. So: thank you for test case, proposed patch; I will try to get working on this issue today. |
@fangzhen Looking at code I now understand your comments, and yes, you are right in that some pieces are missing. But this might be even trickier in that type information for container must basically be ignored as it can not be used for constructing new container (since existing one is to be used). |
Just adding label so that I remember to re-evaluate this as part of 2.9 work; no guarantees it can be fixed but should be attempted. |
It cause can not storage org.apache.shiro.subject.SimplePrincipalCollection in redis |
I have this issue |
Hey @cowtowncoder I am facing this issue in version 2.15 , I am using kotlin data classes any pointers would help. |
@vpatil1311 this issue, is reproduced in java. You may do either of the following
|
What @JooHyukKim said, but additionally upgrade first to 2.17.1 (even if just for testing) to see if something has been fixed. |
Hi @JooHyukKim @cowtowncoder my test code is here FasterXML/jackson-module-kotlin#809 I am using version 2.17.1 |
@srusanvin Assuming this is the same issue, you are better of figuring how to avoid use of "setterless" getters. First, disable
and then you won't be hitting the same issue. And I doubt it's something you'd expect to happen; there needs to be either Field to set, or setter method, for whichever property was attempted to be set via getter (that is: getter used to access |
When deserialize setterless properties with type info
the deserializer throws an exception:Here's an example to make it clear:
I traced the execution, and have found something.
doesn't initiate
_valueTypeDeserializer
forsetterlessProperty
. Anddoesn't test if the
_valueTypeDeserializer
exists, probably correspond with the former. However, I think it should test it asSettableBeanProperty
does. Unfortunately, theTypeDeserializer
didn't give interface to deserialize to a given Object.The text was updated successfully, but these errors were encountered: