Нулевой тип контента при миграции с Джерси на RESTEasy. - PullRequest
3 голосов
/ 22 июня 2010

Итак, я написал пример ресурса REST, который работает как брелок в Джерси / 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) в org.jboss.resteasy.core.MethodInjectorImpl.injectArguments (MethodInjectorImpl.java:98) в org.jboss.resteasy.core.MethodInjectorImpl.invoke (MethodInjectorImpl.java:121) в org.jboss.resteasy.core.ResourceMethod.invokeOnTarget (ResourceMethod.java:247) в 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>

Ответы [ 5 ]

4 голосов
/ 28 сентября 2010

Классическая причина этого, если у вас есть такой код:

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

... и вы забыли аннотировать аргумент bar с помощью @PathParam. Затем RestEasy считает, что должна быть строка чтения из тела запроса, а не из URL-пути, и изменит это исключение.

Это не похоже на то, что происходит в вашем случае, но я получил то же исключение, и это было причиной.

4 голосов
/ 22 июня 2010

Код, который генерирует это исключение, выглядит следующим образом:

     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 в том, что может быть ошибкой вашего кода.

1 голос
/ 28 февраля 2012

Ну, я знаю, что этот запрос датирован, и так много в интернете старое .. через два года все обычно меняется и работает лучше. Таким образом, RestEasy не должен получить плохой рэп по сравнению с другими несобственными средами RESTLET.

На самом деле, я думаю, что JBoss RestEasy занимает наименьшую площадь, не раздутая ненужными * .jars, гибкой, полностью сертифицированной реализацией JAX-RS, полной и ее простота использования не поддается сравнению

Некоторые ускользали от того, что GET-запрос не должен ожидать Content_Type для запроса, (и я согласен), но при каждом GET-запросе необходимо указывать, что вы намереваетесь отправить обратно запрашивающему? Правильно! (это будет JSON, XML, обычный текст, XML и лист, многокомпонентный и т. д.). Что ж, RestEasy, платформа JBoss решает эту проблему с помощью аннотации, как показано ниже, и настраивается для каждого запроса REST URL. Следовательно, в этом ваш ответ

 @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());  
}   
1 голос
/ 22 июня 2010

RestEASY vs Jersey трудно сказать: http://www.infoq.com/news/2008/10/jaxrs-comparison

Что касается вашей ошибки, вы можете контролировать тип контента с помощью аннотаций, что произойдет, если вы разместите @ Производит аннотацию , например:

@Produces("application/json")
@GET
public Response getData() {
  ...
}
0 голосов
/ 22 июня 2010

запрос GET не должен иметь тело , а приложение не должно содержать заголовок Content-Type.

Если это ошибка RestEASY, возникает вопрос, сколько людей действительно используют программное обеспечение.

РЕДАКТИРОВАТЬ

RFC2616 $ 4,3

Тело сообщения НЕ ДОЛЖНО быть включено в запрос, если спецификация метод запроса (раздел 5.1.1) не разрешать отправку объекта-тела в запросы.

Сервер ДОЛЖЕН прочитать и переслать тело сообщения по любому запросу; если метод запроса не включает определенная семантика для тела объекта, тогда тело сообщения ДОЛЖНО быть игнорируется при обработке запроса.

Метод GET не "не позволяет отправлять тело объекта в запросе" , поэтому запрос GET МОЖЕТ иметь тело. Но GET "не включает в себя определенную семантику для тела сущности" , поэтому тело в любом случае следует игнорировать.

В любом случае RestEASY не должен был требовать наличия Content-Type в запросе GET.

...