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.
