How to get type information to Deserializer initialized through Annotation 3.0.0-rc6 #5254
Replies: 0 comments 2 replies
-
Maybe this belongs to the databind repo as a bug report? |
Beta Was this translation helpful? Give feedback.
-
The lack of type information during actual deserialization calls is by design, to limit amount of information to pass (and to keep around for passing): this is not and more importantly, will not be made, available. Type information must instead be used when constructing and/or initializing deserializer. So usually when callback is made to Annotations will be accessible in NOTE: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm trying to cook up a scheme to create custom (de)serializers for a class where I can just implement a couple of (probably static) methods that would pair with "generic" (de)serializer classes that knew how basically duck-type the class to call the method that it needed to get the job done.
The issue is that there is no class information that I can find in the context when (de)serialize is called, and the same goes for resolve() (verified in deserializer construction). At the moment, I'm looking at DeserializationContextExt.java line 209, where it's calling
deser.resolve(this)
. I've don't see where DeserializationContextExt has the class that the deserializer is being registered for. I've evaluated the obvious method calls in the debugger (i.e.getContextualType()
) returns null. The same is true when the context is passed into thedeserialize()
call, and as far as I can tell, this makes it impossible to know what class we're dealing with.I can see, however, that in the
Annotated ann
method parameter for this section of code does know the class that the deserializer is being created for. I assume that there is a similar situation for when a serializer is constructed, but I have not verified.Is there a way to get the information from the
Annotation ann
method parameter into the deserialzation context (hopefully good), or passing the ann parameter into resolve (probably bad)? I assume that adding this information to the context would also fix it for the case where deserialize is called, and a similar fix for registering serializers would work as well.Thanks!
Attached is a screenshot of the code in-debugger that hopefully confirms what I have asserted above.
Beta Was this translation helpful? Give feedback.
All reactions