Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The field IDs for Instant and Date were ignored during the conversion so the generated JSON was an empty string. The fix was a bit more convoluted. I'll explain all I have and maybe there's a better solution.
Instant
is converted by theWrappedMessage
tobyte[]
by writing oneint64
field for seconds andint32
for nanos.message-wrapping.proto
file describes the seconds part as aoneOf
which writes the key as"_value"
. We still need to write to fields, so we end with{"_value": 0, "wrappedInstantNanos": 0}
without any typing.WrappedMessage
, but the conversion from JSON toInstant
would fail as it creates theInstant
inside theWrappedMessage
object. So we need an explicit type for the conversion to create the correct object.Since we need this conversion from JSON to
Instant
to work, I've created an adapter in thetypes
module. During the Proto to JSON conversion, we require this adapter to be registered so we can write the field names and the type correctly.We are still left with converting JSON to Proto
byte[]
. We need to verify in theWrappedMessage
class whether this object corresponds to a known type. Otherwise, the generatedbyte[]
will be entirely different from the one produced byInstant
to Protobyte[]
serialization.The
Date
object suffers from the same thing. The difference is that:Date#getTime
method.{"_type": "int64", "_value": 12345}
. Which loses any type parameter that this value is aDate
object.Date
will fail as it returns a primitivelong
number instead of theDate
object.Closes #405.