2015-12-23 5 views
4

Я использую Джерси 1.21.1, и я получаю странное поведение при датах отмены.Джерси (MOXy) усекающий JSON даты

Упрощенная версия моего POJO:

@XmlRootElement 
public class Invoice { 
    private Date invoiceDate; 
    private Date invoiceDate2; 
} 

Мой метод ресурс:

@PUT 
@Consumes(MediaType.APPLICATION_JSON) 
public Response putInvoice(Invoice invoice) { .. } 

код JavaScript, который вызывает эта служба использует JSON.stringify для получения следующего запроса HTTP полезной нагрузки (это то, что было на самом деле отправлено в соответствии с отладчиком Chrome):

{"invoiceDate": "2015-10-27T 04: 00: 00.000Z "," invoiceDate2 ":" 2015-10-27T08: 00: 00.000Z "}

Пока все хорошо. Но когда я останавливаюсь в контрольной точке внутри putInvoice и изучить Java даты invoice.invoiceDate и invoice.invoiceDate2, они оба имеют один и тот же fastTime:

(который равен 27 октября, 2015 12:00:00 UTC).

Я нахожусь в недоумении, почему Джерси/МОКСы, похоже, не могут разобрать то, что выглядит мне как стандартная дата UTC ISO. Я могу только предположить, что я делаю что-то неправильно или делаю плохое предположение. Помощь будет принята с благодарностью.

ответ

2

Основная причина проблемы заключалась в том, что мое поле даты POJO было объявлено как java.sql.Date, а не java.util.Date. Формат ISO действительно корректно обрабатывается при разборке до java.util.Date.

Очевидным решением является использование java.util.Date в POJO. Но если по какой-то причине java.sql.Date нужен, вы можете написать обычай XmlAdaptor делать синтаксический анализ и форматирование (см ответ на этот SO вопрос: jaxb unmarshal timestamp)

Дополнительные комментарии: это не все, что удивительно, что java.sql.Date не работает с Джерси/МОКСИ из коробки, но я нахожу, что конкретный сбой поражает. Честно говоря, я бы и ожидал, и предпочел исключение преобразования класса, как тот, который я получил, когда попытался написать свой собственный XmlAdaptor. Вот как я в конце концов понял причину.

Поскольку MOXy урезал время, мне интересно, не исключено ли, что исключение в синтаксическом анализе даты и времени по умолчанию приводит к тому, что MOXy возвращается к дате. Но если да, то как этот резерв успешно присваивал java.sql.Date, когда исходная логика не могла? Это тайна, но не та, которую я планирую проводить в любое время. (Редактировать: это объяснение, вероятно, неверно - см. Комментарий)

+0

Что-то еще я должен был заметить раньше: Jersey + MOXy делает то же самое усечение, когда он маршалирует java.sql.Date. То есть, когда я делаю HTTP GET на ресурсе, в строке даты нет компонента времени или часового пояса, например. '2015-12-15'. Таким образом, мое предположение, что это было непреднамеренно вызвано обработкой исключений, кажется неправильным. Это непротиворечиво и, следовательно, чувствует себя преднамеренным, но я затрудняюсь объяснить, почему с java.sql.Date следует обращаться таким образом. – Bampfer