从Jersey迁移到RESTEasy时为空内容类型。

Question

因此，我编写了一个示例REST资源，它在泽西/ Tomcat中像一个魅力一样工作，但是当我将它放到RestEASY/Tomcat时，它就会大打折扣。我的意思是真的？开箱即用发生了什么事。无论如何，有点沮丧。我在尝试访问该资源（http://localhost:7070/mg/mytest）

“内容类型为null，并期待提取体”

7842 [HTTP-7070-2] ERROR com.loyalty.mg当这个错误.rest.exception.MGExceptionMapper - 在异常映射器中捕获的错误 - org.jboss.resteasy.spi.BadRequestException：content-type为空，并期望在org.jboss.resteasy.core.MessageBodyParameterInjector.inject（）中提取一个正文 MessageBodyParameterInjector.java:131） at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments（MethodInjectorImpl.java:98） at org.jboss.resteasy .core.MethodInjectorImpl.invoke（MethodInjectorImpl.java:121） at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget（ResourceMethod.java:247） at org.jboss.resteasy.core.ResourceMethod.invoke（ResourceMethod.java ：212） 在org.jboss.resteasy.core.ResourceMethod.invoke（ResourceMethod.java:202）

@Path("/mytest") 
public class TestResource { 

    @GET 
    public Response getData() 

我想这个问题也是 - 是RestEasy的比任何泽西更好，这仅仅是个开始和我收到错误。我应该坚持泽西岛吗？

而且已经尝试过这个问题，以及:)

<context-param> 
    <param-name>resteasy.media.type.mappings</param-name> 
    <param-value>json : application/json, xml : application/xml</param-value> 
</context-param> 

Answer 1

抛出该异常的代码看起来是这样的：

 final MediaType mediaType = request.getHttpHeaders().getMediaType(); 
    if (mediaType == null) { 
     throw new BadRequestException(
      "content-type was null and expecting to extract a body"); 
    } 

这个问题似乎是RestEasy的不能想出一个内容类型它收到的请求的标题。这表明要么请求中的内容类型是假的，要么是您配置RestEASY的方式存在问题。

我想这个问题也是 - RestEASY比泽西更好，这只是一个开始，我得到的错误。我应该坚持泽西岛吗？

我无法回答。不过，我认为你太快责怪RestEASY，因为可能是是你的代码的错。

Answer 2

RestEasy的VS篮网是很难说的： http://www.infoq.com/news/2008/10/jaxrs-comparison

关于你的错误，你可以控制通过注释的内容类型，会发生什么，如果你把@Produces annotation，例如：

@Produces("application/json") 
@GET 
public Response getData() { 
    ... 
} 

Answer 3

一GET请求不得具有正文，并且应用程序不得延长Content-Type标头。

如果这是一个RestEASY的错误，它让人怀疑有多少人确实正在使用该软件。

EDIT

RFC2616 $ 4.3

消息正文不得 可以包括一个请求，如果请求 方法的规范（第5.1.1节）不 不允许发送 请求中的实体主体。

服务器应该在任何请求上读取并转发一个 消息体;如果 请求方法不包括 为实体主体定义的语义 那么在处理请求时忽略消息主体 。

GET方法不“不允许请求发送实体主体”因此GET请求可以具有体。但GET “不包含实体主体的定义语义”因此无论如何都应该忽略主体。

在任何情况下，RestEASY都不应要求在GET请求中存在Content-Type。

Answer 4

一个经典的原因，就是如果你有这样的代码：

@GET 
@Path("/foo/{bar}") 
@Produces(MediaType.TEXT_HTML) 
public Response foo(@PathParam("bar") String bar) { 

...你忘了注释与@PathParam酒吧的说法。然后RestEasy认为它应该是从请求的主体读取而不是从URL路径中读取，并且会抛出这个异常。

这似乎不是你的情况发生了什么，但我得到了同样的例外，这是原因。

Answer 5

嗯，我知道这个请求是过时的，在互联网上这么多老..在一年的一切通常会改变和更好地工作。因此，与其他非属性的RESTLET框架相比，RestEasy不应该得到一个糟糕的说唱。

实际上，我认为JBoss RestEasy具有最轻的占位面积，它不会因不必要的* .jars，灵活且完全认证的JAX-RS实现而臃肿，完整且易于使用是无法比拟的。

有些人不明白，GET请求不应该期待请求上的Content_Type，（我同意），但是每个GET请求都必须指明你打算发回给请求者的内容？对！ （将它是JSON，XML，纯文本，XML和一个图表，多部分等）。 RestEasy，JBoss的框架如下所示用注释解决这个问题，并且可以根据URL REST请求进行配置。 因此，此处是你的答案

@GET 
@Path("/echo/{message}") 
@Produces("text/plain") 
public String echo(@PathParam("message")String message){ 
    return message;  
} 

@GET 
@Path("/employees") 
@Produces("application/xml") 
@Stylesheet(type="text/css", href="${basepath}foo.xsl") 
public List<Employee> listEmployees(){ 
    return new ArrayList<Employee>(employees.values()); 
} 

@GET 
@Path("/employee/{employeeid}") 
@Produces("application/xml") 
public Employee getEmployee(@PathParam("employeeid")String employeeId){ 
    return employees.get(employeeId);   
} 

@GET 
@Path("/json/employees/") 
**@Produces("application/json")** 
public List<Employee> listEmployeesJSON(){ 
    return new ArrayList<Employee>(employees.values()); 
}