fix Issue #676 - "explicit" nulls within RuntimeTypeAdapterFactory#677
fix Issue #676 - "explicit" nulls within RuntimeTypeAdapterFactory#677lcoote wants to merge 1 commit into
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
|
I signed it! |
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
Using custom TypeAdapters, it is possible to force null values within a particular type to be explicitly serialized, by overriding the setSerializeNulls setting on the supplied JsonWriter. However, this behavior fails in the context of a RuntimeTypeAdapterFactory because a second JsonTreeWriter is used and settings are not propagated from one to the other. This change fixes this by: - propagating the original setSerializeNulls setting to the created JsonTreeWriter - temporarily forcing the setSerializeNulls setting to true on the oriiginal JsonWriter to ensure any explicit nulls are preserved. Issue google#676
|
CLAs look good, thanks! |
Using custom TypeAdapters, it is possible to force null values within a
particular type to be explicitly serialized, by overriding the
setSerializeNulls setting on the supplied JsonWriter.
However, this behavior fails in the context of a
RuntimeTypeAdapterFactory because a second JsonTreeWriter is used and
settings are not propagated from one to the other.
This change fixes this by:
JsonTreeWriter
oriiginal JsonWriter to ensure any explicit nulls are preserved.
Issue #676