You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
An edge case exists in the virtual class field deserialization routine,
where data intending to be deserialized as an array will instead be deserialized to
an ArrayList because there exists no type information to determine the representation
to use. For most cases, the method cache will be available to use for this type information,
but when using Service.sendBlocking() the callback method usually does not exist and therefore
no type information is available. An example use case where this would be a problem is when
calling a remote method using sendBlocking() that has an array return type.
Recommended Solution
The solution I recommend is adding a similar functionality as Service.blockingList to CodecUtils
that contains the type information for an expected message. The entries for this map will be set by Service.sendBlocking() just like the blockingList map. When CodecUtils.jsonToMessage() (from #1211) is called, it will check this map to see if the type information is available, and if so will pass it to the deserialization routines before removing it from the map (to avoid memory leaks, the type information shouldn't change otherwise). This will stop this edge case from being triggered by Service.sendBlocking() which is the only instance I know of.
The text was updated successfully, but these errors were encountered:
Describe the bug
An edge case exists in the virtual class field deserialization routine,
where data intending to be deserialized as an array will instead be deserialized to
an
ArrayList
because there exists no type information to determine the representationto use. For most cases, the method cache will be available to use for this type information,
but when using
Service.sendBlocking()
the callback method usually does not exist and thereforeno type information is available. An example use case where this would be a problem is when
calling a remote method using
sendBlocking()
that has an array return type.Recommended Solution
The solution I recommend is adding a similar functionality as
Service.blockingList
to CodecUtilsthat contains the type information for an expected message. The entries for this map will be set by
Service.sendBlocking()
just like the blockingList map. WhenCodecUtils.jsonToMessage()
(from #1211) is called, it will check this map to see if the type information is available, and if so will pass it to the deserialization routines before removing it from the map (to avoid memory leaks, the type information shouldn't change otherwise). This will stop this edge case from being triggered byService.sendBlocking()
which is the only instance I know of.The text was updated successfully, but these errors were encountered: