3

所以我写了一个示例 REST 资源，它在 Jersey/Tomcat 中就像一个魅力，但是当我把它带到 RestEASY/Tomcat 时它会爆炸。我是说真的吗？开箱即用发生了什么。总之有点沮丧。尝试访问资源时出现此错误（http://localhost:7070/mg/mytest）

“内容类型为空并期望提取正文”

7842 [http-7070-2] 错误 com.loyalty.mg.rest.exception.MGExceptionMapper - 异常映射器中捕获的错误 - org.jboss.resteasy.spi.BadRequestException：内容类型为空并期望在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) at 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>
4

5 回答 5

4

The code that throws that exception looks like this:

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

The problem seems to be that RestEASY cannot figure out a content type from the headers of the request that it received. This suggests that either that the content type in the request is bogus, or that there is a problem with the way that you have configured RestEASY.

I guess the question also is - is RestEASY any better than Jersey, this is just the start and I am getting errors. Should I just stick to Jersey?

I cannot answer that. However, I think you are being too quick to blame RestEASY for something that could be your code's fault.

于 2010-06-22T03:00:03.453 回答
4

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

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

...并且您忘记使用@PathParam 注释 bar 参数。然后 RestEasy 认为它应该从请求的正文中读取 bar，而不是从 URL 路径中读取，并将丢弃此异常。

这似乎不是你的情况，但我遇到了同样的例外，这就是原因。

于 2010-09-28T17:08:20.957 回答
1

RestEASY vs Jersey 很难说： http: //www.infoq.com/news/2008/10/jaxrs-comparison

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

@Produces("application/json")
@GET
public Response getData() {
  ...
}
于 2010-06-22T03:44:33.663 回答
1

好吧，我知道这个要求已经过时了，互联网上的很多东西都是旧的……在两年的一年里，一切通常都会改变并且效果更好。因此，与其他非专有 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());  
}
于 2012-02-28T17:01:56.057 回答
-1

GET 请求不能有 body，并且应用程序不能扩展 Content-Type 标头。

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

编辑

RFC2616 4.3 美元

如果请求方法的规范（第 5.1.1 节）不允许在请求中发送实体主体，则消息主体不得包含在请求中。

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

GET 方法“不允许在请求中发送实体主体”，因此 GET 请求可能有主体。但是 GET “不包括实体主体的定义语义”，因此无论如何都应该忽略主体。

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

于 2010-06-22T05:04:57.240 回答