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

Question

So I wrote a sample REST resource that works like a charm in Jersey/Tomcat, but when I take it to RestEASY/Tomcat it blows. I mean really? what happened to working out of the box. Anyway a little frustrated. I get this error when trying to access the resource( http://localhost:7070/mg/mytest )

"content-type was null and expecting to extract a body"

7842 [http-7070-2] ERROR com.loyalty.mg.rest.exception.MGExceptionMapper - Error caught in the exception mapper - org.jboss.resteasy.spi.BadRequestException: content-type was null and expecting to extract a body at 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()

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?

Also already tried this as well :)

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

Answer 1

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.

Answer 2

A classic cause of this, is if you have code like this:

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

...and you forget to annotate the bar argument with @PathParam. Then RestEasy thinks it should be reading bar from the body of the request, instead of from the URL path, and will chuck this exception.

That doesn't seem to be what's happening in your case, but I got the same exception, and this was the cause.

Answer 3

RestEASY vs Jersey is hard to say: http://www.infoq.com/news/2008/10/jaxrs-comparison

Regarding your error, you can control the content type via annotations, what happens if you place @Produces annotation , for example:

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

Answer 4

Well I know this requested is dated, and so much on the internet old..in a year of two everything usually changes and works better. So RestEasy should not get a bad rap in comparison to other non-propertary RESTLET frameworks.

Actually I think JBoss RestEasy has the lightest footprint, it's not bloated with unnecessary *.jars, flexible, fully certified JAX-RS implementation, complete and its ease of use is beyond comparison.

Some eluded, that a GET request should not expect a Content_Type on the request, (And I agree), but with a every GET request one must indicate what you intend on sending back to the requestor? Right! (will it be JSON, XML, plain text, XML and a sheetsheet, multi-part, etc). Well RestEasy, JBoss's framework addresses this with annotation as shown below, and configurable per URL REST request. Therefore, therein is your answer

 @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());  
}   

Answer 5

a GET request must not have a body , and an application must not expet a Content-Type header.

If this is a bug of RestEASY, it makes one wonder how many people really are using the software.

EDIT

RFC2616 $4.3

A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests.

A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

The GET method does not "does not allow sending an entity-body in request" therefore a GET request COULD have a body. But GET "does not include defined semantics for an entity-body" therefore the body should be ignored anyway.

In any case, RestEASY should not have required the presence of Content-Type in a GET request.