泽西岛:JSON和StringMessageProvider冲突，应用程序/json方法生成无效的JSON [英] Jersey: JSON and StringMessageProvider clash, application/json methods generate invalid JSON

问题描述

我在jetty + jersey上有一个jax-rs网络服务，并尝试了不同的JSON消息提供程序(例如Jackson和Gson). 通过所有这些，POJO<-> JSON可以很好地工作，但是这样的方法:

I have a jax-rs web services on jetty+jersey and tried different JSON message providers (e.g. Jackson and Gson). With all of them POJO <-> JSON works just fine but methods like this:

@GET
@Path("test")
@Produces(MediaType.APPLICATION_JSON)
public String test() {
    return "This string should be \"quoted\" by message writer";
}

产生字符串

This string should be "quoted" by message writer

这当然不是有效的JSON，并且会导致浏览器的ajax调用失败. 我希望是

which is of course not a valid JSON and causes browser's ajax calls to fail. I expect it to be

"This string should be \"quoted\" by message writer"

之所以如此神奇，是因为StringMessageProvider(基本类型的内部球衣提供程序之一)具有/ Produce/Consume注释.而且我不想侵入球衣内部提供商.我想强制球衣首先使用JSON提供程序吗?

The reason for such magic is StringMessageProvider (one of the internal jersey providers for basic types) which have / Produce/Consume annotation. And I don't want to hack into jersey internal providers. I want to force jersey to use JSON provider in first place?

有什么想法吗?

推荐答案

因此，阅读球衣文档&一些调试结果表明:

So, after reading jersey docs & some debuging it turned out that:

• 是的，自定义消息阅读器/编写器具有更高的优先级，但是
• 选择合适的"提供者(从正确的提供者开始)后，球衣通过自定义比较对它们进行排序，首先检查类型"距离

因此，具有方法返回类型'String'和JSON消息提供程序MIME类型通配符(/)，它通过比较距离String-String来检查第一个StringMessageProvider(内置类型的默认球衣提供程序) <字符串对象.

So, having method return type 'String' and JSON message provider MIME type wildcard (/), it checks first StringMessageProvider (default jersey provider for build-in type) by comparing distances String-String < String-Object.

通过添加非通用自定义消息提供程序(例如:

The problem solved by adding non-generic custom message provider, e.g.:

public class StringProvider extends GsonProvider<String> {
    public StringProvider() {}
}

(其中GsonProvider implements MessageBodyReader<T>, MessageBodyWriter<T>).

将此返回的字符串转义为正确的JSON，并被浏览器的ajax调用处理程序识别.

After this returned string was escaped to be a correct JSON and recognized by browsers' ajax call handlers.

这篇关于泽西岛:JSON和StringMessageProvider冲突，应用程序/json方法生成无效的JSON的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！