我正在使用 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 调试器，这是实际发送的内容):到现在为止还挺好。但是当我停在
putInvoice 内的断点处并检查 Java 日期 invoice.invoiceDate 和 invoice.invoiceDate2 时，它们都具有相同的 fastTime:(相当于世界标准时间 2015 年 10 月 27 日上午 12:00:00)。
我不知道为什么 Jersey/MOXy 似乎无法解析在我看来像标准 ISO UTC 日期的内容。我只能假设我做错了什么或做出了错误的假设。帮助将不胜感激。
最佳答案
问题的根本原因是我的 POJO 日期字段被声明为 java.sql.Date ，而不是 java.util.Date 。解码到 java.util.Date 时，确实可以正确解析 ISO 格式。
显而易见的解决方案是在 POJO 中使用 java.util.Date。但是，如果由于某种原因需要 java.sql.Date，您可以编写自定义 XmlAdaptor 来进行解析和格式化(请参阅此问题的答案: jaxb unmarshal timestamp )
附加评论:java.sql.Date 不能与 Jersey/MOXy 一起开箱即用并不奇怪，但我确实发现特定的失败令人惊讶。坦率地说，我既期望又喜欢类转换异常，就像我尝试编写自己的 XmlAdaptor 时遇到的那样。这就是我最终找出根本原因的方式。
由于 MOXy 截断了时间，我想知道这是否是因为默认日期时间解析中的异常导致 MOXy 回退到仅日期。但如果是这样，当原始逻辑不能时，该回退如何成功分配给 java.sql.Date ？这是一个谜，但我不打算花任何时间。 (编辑:这个解释可能是错误的——见评论)