我正在使用Jersey 1.21.1并且在解组日期时会出现奇怪的行为.
我的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-27T04:00:00.000Z”,”invoiceDate2″:”2015-10-27T08:00:00.000Z”}
到现在为止还挺好.但是当我停在putInvoice内的断点并检查Java日期invoice.invoiceDate和invoice.invoiceDate2时,它们都具有相同的fastTime:
1445904000000
(等于2015年10月27日凌晨12:00:00 UTC).
我不知道为什么Jersey / MOXy似乎无法解析看起来像标准ISO UTC日期的东西.我只能假设我做错了什么或做出了错误的假设.非常感谢帮助.
最佳答案 问题的根本原因是我的POJO日期字段被声明为java.sql.Date,而不是java.util.Date.在解组为java.util.Date时,确实正确解析了ISO格式.
显而易见的解决方案是在POJO中使用java.util.Date.但是如果由于某种原因需要java.sql.Date,你可以编写一个自定义的XmlAdaptor来进行解析和格式化(参见这个SO问题的回答:jaxb unmarshal timestamp)
附加评论:java.sql.Date不能与Jersey / MOXy开箱即用,这并不奇怪,但我确实发现特定的失败令人惊讶.坦率地说,我会同时期望和首选类转换异常,就像我在尝试编写自己的XmlAdaptor时得到的那样.这就是我最终找出根本原因的方法.
由于MOXy截断时间,我想知道是否因为默认日期时间解析中的异常导致MOXy仅回落到日期.但如果是这样,当原始逻辑不能时,该回退如何成功分配给java.sql.Date?这是一个谜,但不是我计划花的时间. (编辑:这个解释可能是错误的 – 见评论)