Interesting, I'll double check but before the upgrade (very old version of Dropwizard/jackson 0.7) the service returns the date as long, and after the upgrade the same call returns as formatted date.
Anyhow many thanks for your answer :-) Gemma El viernes, 12 de mayo de 2017, 20:38:31 (UTC+1), Steve Kradel escribió: > > Are you sure a java.sql.Date or similar hasn't gotten its way into the > works? yyyy-MM-dd is the default serialization format for java.sql.Date, > but a java.util.Date remains very much a wrapper around a long int. > > On Friday, May 12, 2017 at 11:08:38 AM UTC-4, Gemma Cabero Colmenero wrote: >> >> Hi, >> >> I'm on a quest to upgrade our application that uses dropwizard (several >> web services) to 1.0.2 The issues have become from the underlaying apis >> (jersey 2, jackson). It seems is almost there but one of our services >> (written in python) is not able to process the answer from a java one due >> to the change of the json representation of a date. It used to be long but >> now the json object containg a date follows this format: "YYYY-MM-DD". >> Although we could change the python service to understand the new date >> format we would prefer keeping the long one as it contains the timezone, >> something important when services may run in different AWS containers. Is >> this something that you were aware? I'm trying to understand where the >> problem comes from as for what I was reading it uses jackson 2.7.4 which >> should return longs when dates are serialised? >> >> >> Many thanks, >> Gemma >> > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
