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