ZonedDateTime field limits interoperability

[dturanski]

Currently the time field is a ZonedDateTime. This requires a custom deserializer ZonedDateTimeDeserializer implemented with jackson. Sending a CloudEvent via http then causes problems on the receiving end. IMHO It would be better to represent time with a more portable type, e.g., long.

[tenczar]

The CloudEvent spec defines the time field as a RFC 3339 timestamp. All of the sdks read/write this format because it contains enough information to fully identify what time is being represented. Using a long strips the timestamp of necessary timezone information. Why not use the sdk on both the producer and consumer?

[dturanski]

I'm using the SDK on both sides, but the JSON serialization happens at another level, based on spring MVC, but uses GSON in this case. GSON does not know how to deserialize ZonedDateTime which results in an error. Is there a way to satisfy the spec without relying on Jackson? @dsyer - FYI

[matzew]

Hi, just returning from the holiday break. It seems to be a limitation on GSON itself:

google/gson#1059 (comment)

Looks like a custom TypeAdapter is needed ? 😞

[dturanski]

I think it's more a limitation of JSON itself. Any Java deserializer will need custom configuration if, e.g., a type does not have a default constructor. Jackson requires ZonedDateTimeDeserializer and GSON requires the corresponding thing. This makes DefaultCloudEventImp less usable. Would it be possible to represent time as a more JSON friendly value object that validates RFC 3339? Another potential work-around is to receive the data as a Map and manually convert that to a CloudEvent.

[matzew]

I think we could try that - it's IMO a PITA that we face this limitation :-(

…

On Mon, Jan 7, 2019 at 2:38 PM David Turanski ***@***.***> wrote: I think it's more a limitation of JSON itself. Any Java deserializer will need custom configuration if, e.g., a type does not have a default constructor. Jackson requires ZonedDateTimeDeserializer and GSON requires the corresponding thing. This makes DefaultCloudEventImp less usable. Would it be possible to represent time as a more JSON friendly value object that validates RFC 3339? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJnzuWS2F7EJJONGjoKmljaoXD_xO7Yks5vA0xQgaJpZM4ZoTgX> .

-- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf

[fabiojose]

@dturanski Any insights on that?

[dturanski]

I would go with a String representation of the ISO-8601 standard. ZonedDateTime.now( ZoneOffset.UTC ).format( DateTimeFormatter.ISO_INSTANT ) This will make the date-time portable. It requires the application to parse it, e.g., ZonedDateTime.parse(zdtAsString).

[fabiojose]

@dturanski Could you create a PR with this solution?

[dturanski]

@fabiojose - I'll see what I can do

[dturanski]

The PR addresses the date issue but more is needed for GSON compatibility in general. There are numerous Jackson annotations now which make CloudEventImpl less compatible with other json libraries. A fully portable object will need a zero arg constructor and flattened attributes to begin with.

[AceHack]

Any updates on this?

[dturanski]

@fabiojose - Any thoughts on merging the PR? @AceHack - Is there a specific issue you are dealing with?

[slinkydeveloper]

Hi @dturanski, I think i'm going to mark this issue as invalid since in sdk v2 we don't use anymore jackson annotations and the implementation of json ser/de is hugely simplified thanks to the Message api. You can easily implement a json serializer/deserializer for GSON similar to what is done for https://github.com/cloudevents/sdk-java/tree/master/formats/json-jackson.
We're also happy to accept a contribution for a json format using GSON!