Jersey client cannot parse replies from RESTEasy server about apicurio-registry HOT 8 CLOSED

@EricWittmann well, this is no a bug ... it's a misconfiguration between server and client json Date serializers ...

It looks like Jackson JSON DateSerializer uses longs ...

• For efficiency, we will serialize Dates as longs, instead of
• potentially more readable Strings.

... where as Yasson expects Date in string format ... ?

Since the user can control its client easier the (s)he can control server,
I would say it's on the user/client to match server's configuration.

from apicurio-registry.

@alesj Well, but if I deploy the converter into Kafka Connect, how can I configure it so it matches the server?

from apicurio-registry.

@jpechane Hmm ... I would guess there must be a way to config this stuff ...
Otoh, @EricWittmann @jsenko wdyt if we changed this createdOn, etc to plain timestamp ourselves -- pure long ... that way it would be solved for all ...

from apicurio-registry.

@alesj The only way I've found is adding annotation to the offending fields - in this case the mapping would be unambiguous

from apicurio-registry.

Like I wrote, I think we can easily change this to plain long timestamp, as I think for us it's not that important that that is a Date instance. It's just an informative field / value ...

from apicurio-registry.

+1 to changing to Timestamp if that fixes this issue. I don't much care whether it's a Date or a Timestamp. Are there any storage layer consequences to doing that?

from apicurio-registry.

Are there any storage layer consequences to doing that?

Doesn't look like it ...

from apicurio-registry.

Fixed by #240

from apicurio-registry.