Jersey（MOXy）截断JSON日期

Question

我将使用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 日期的内容。我只能假设我做错了什么或者做出了错误的假设。非常感谢您的帮助。

- Bampfer

Answer 1

问题的根本原因在于我的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，而原始逻辑无法呢？这是个谜，但我不打算花时间去解决它。（编辑：这个解释可能是错误的--请参见评论）

- Bampfer

---

我之前应该注意到的另一件事是：当Jersey + MOXy编组java.sql.Date时，它会执行完全相同的截断。也就是说，当我在资源上执行HTTP GET时，日期字符串没有时间组件或时区，例如“2015-12-15”。因此，我之前的猜测是由于异常处理不当而引起的似乎是错误的。这是一致的，因此看起来是故意的，但我无法解释为什么java.sql.Date会被这样处理。 - Bampfer