我正在使用 Jersey 构建服务的 REST API。我希望能够接受并返回 JSON 和 XML，并且大部分都能正常工作，但我不喜欢 Jersey 喜欢吐出的默认“映射”风格的 JSON。
我知道较新的“自然”符号（来自 http://jersey.java .net/nonav/documentation/latest/json.html，我将详细引用它，因为它使默认“映射”符号的问题变得显而易见）：
使用映射 JSON 表示法一段时间后，很明显，
需要手动配置所有各种东西可能有点
有问题的。为了避免手动工作，一种新的、自然的 JSON 表示法
在 Jersey 版本 1.0.2 中引入。用自然记数法，Jersey
会自动计算出各个项目需要如何
处理，这样你就不需要做任何类型的手动
配置。 Java 数组和列表被映射为 JSON 数组，甚至
对于单元素情况。 Java 数字和布尔值是正确的
映射为 JSON 数字和布尔值，您无需费心
使用 XML 属性，就像在 JSON 中一样，它们保留原始名称
并希望在任何地方使用它，但我一直不知道如何做。我正在通过 Tomcat 的 XML 配置文件实例化/配置 Jersey——使用我认为是 servlet/servlet-class/init-param 标签的正常舞蹈——但我无法找到关于它是否或如何的文档可以从那里指定 JSONConfiguration 选项。
我还尝试实现我自己的 ContextResolver，它应用我从 Java 代码实例化的 JSONJAXBContext，我可以在其中应用 JSONConfiguration.natural() （示例如下所示 这个答案）。这有效，但仅适用于我在该代码中明确列出并传递给 JSONJAXBContext 构造函数的类型。如果我添加更多数据类，这些额外的代码不仅需要编写和维护，并且需要更改，而且它不适用于 List 之类的东西。
有没有办法告诉 Jersey 对于所有类型始终只使用自然表示法而不是映射表示法？
I'm using Jersey to build a REST API to a service. I'd like to be able to accept and return both JSON and XML, and have this mostly working but I don't like the default "mapped" flavor of JSON that Jersey likes to spit out.
I know about the newer "natural" notation (from http://jersey.java.net/nonav/documentation/latest/json.html, which I'll quote at length because it makes obvious the problems with the default "mapped" notation):
After using mapped JSON notation for a while, it was apparent, that a
need to configure all the various things manually could be a bit
problematic. To avoid the manual work, a new, natural, JSON notation
was introduced in Jersey version 1.0.2. With natural notation, Jersey
will automatically figure out how individual items need to be
processed, so that you do not need to do any kind of manual
configuration. Java arrays and lists are mapped into JSON arrays, even
for single-element cases. Java numbers and booleans are correctly
mapped into JSON numbers and booleans, and you do not need to bother
with XML attributes, as in JSON, they keep the original names
and would like to use it everywhere, but I haven't been able to figure out how to. I'm instantiating/configuring Jersey via Tomcat's XML config files -- using what I believe is the normal dance with servlet/servlet-class/init-param tags -- but I haven't been able to find documentation on whether or how it's possible to specify JSONConfiguration options from there.
I've also tried implementing my own ContextResolver which applies a JSONJAXBContext I instantiated from Java code, where I can apply JSONConfiguration.natural() (an example of this looks like this answer). This works, but only for types I explicitly list out in that code, and pass to the JSONJAXBContext constructor. Not only is this extra code to write and maintain, and change if I add more data classes, but it doesn't work for things like List.
Is there a way to tell Jersey to just use the natural notation instead of mapped notation, always and for all types?
发布评论
评论（1）
我从未找到我在这里提出的实际问题的答案，但我找到了一个简单的三步过程，可以实现与我想要的相同的最终结果：
Jersey 文档突出地提到了这个 POJOMappingFeature/FEATURE_POJO_MAPPING （这是我在问题中链接的文档页面中的第一个示例），但没有准确描述它的含义，并且从该文档呈现其信息的方式来看，我认为这个选项（5.1 ，“POJO 支持”）与选项 5.2（“基于 JAXB 的 JSON 支持”）不一致，这听起来更像我想要的。因此，在尝试启用 FEATURE_POJO_MAPPING 之前，我尝试了很多其他事情。
但一旦我尝试过，它就完全按照我想要的方式工作，而且我不必回头。
这样做的一个附带好处是，与 Jersey 的本机 JSON 处理实现相比，在客户端向其传递虚假 JSON 内容的情况下，Jackson 会生成更好的错误消息。
I never did find an answer to the actual question I was asking here, but instead I found a simple 3 step process that accomplishes the same end result that I wanted:
The Jersey documentation mentions this POJOMappingFeature/FEATURE_POJO_MAPPING prominently (it's the first example in the doc page I linked in the question), but doesn't describe exactly what it means, and from the way that document presents its information I thought this option (5.1, "POJO support") was at odds with option 5.2 ("JAXB based JSON support") which sounded more like what I wanted. So I tried a lot of other things before I tried enabling FEATURE_POJO_MAPPING.
But once I tried it, it worked exactly as I wanted, and I haven't had to look back.
A side benefit of this is that Jackson generates much better error messages in the case that the client passes it bogus JSON content, compared to Jersey's native JSON handling implementation.