是否有可能從RestEASY MessageBodyReaderInterceptor中的MessageBodyReaderContext獲取@PathParam或@QueryParam？

我的服務：是否有可能從RestEASY MessageBodyReaderInterceptor中的MessageBodyReaderContext獲取@PathParam或@QueryParam？

@POST 
public String setData(@QueryParam("id") Long is, MyObject payload) { 
... 
} 

or 

@POST 
public String setData(@PathParam("id") Long is, MyObject payload) { 
... 
}

我在服務器上攔截：

Object read(MessageBodyReaderContext context) throws IOException, WebApplicationException { 

Class mypayloadtype = context.getType; 

InputStream mypayloadinpustream = context.getInputStream(); 


Long myidparam = ???????? // how to get the query or path param here? 

}

編輯：是有點更具體：

我希望做的是搶XML並根據參數將其存儲在單獨的審計系統中。也許PreProcessInterceptor/PostProcessInterceptor是更好的選擇？

當xml仍然可用於預處理時，獲取參數的任何提示或替代方法？

米格爾

來源

2013-02-13 Miguel ZP

我並沒有覺得你應該使用攔截器來進行身體反序列化;我認爲這是通過JAX-RS「MessageBodyReader」子類完成的，並且不應該知道_other_參數。這就是主要的服務方法應該知道處理的內容。 – 2013-02-15 20:47:24

我編輯了這個問題，以明確爲什麼我想使用攔截器。 – 2013-02-20 08:17:23

我不上的話題，但我的專家看來，如果在MessageBodyReaderContext接口並不真正知道這是否是服務器或客戶端上，所以不能暴露請求或者其參數/路徑部分等。

所以據我所知這是不可能的。

如果你的代碼都知道，它生活在休息通信的服務器端，也許你可以使用一個Servlet過濾器來存儲請求在一個ThreadLocal，然後從那裏訪問它，而請求處理，有些類似於彈簧框架中的RequestContextFilter/RequestContextHolder？（然後，請求對象不知道服務註釋的任何內容，而是必須從請求中手動提取信息，這意味着在兩個地方有相同的信息，所以必須有更好的解決方案。。）

編輯：看一些例子後，我得到了模糊的感覺，如果你想讀取輸入流，以創建一個對象並添加路徑參數給它，MessageBodyReaderInterceptor根本就不是要走的路。取而代之的是建立一個MessageBodyReader，它根據請求主體數據構造對象，然後將其傳遞到public String setData(@PathParam("id") Long is, MyObject payload)，假定此方法用與MessageBodyReader的@ConsumeMime註釋相匹配的@Consumes進行註釋。您可能在setData中設置從請求主體讀取的對象上缺少的ID。一些與此相關的例子似乎在這裏：How to get full REST request body using Jersey?（但澤西島，而不是jBoss： - /）

但我不確定這是否適合你，我也覺得我完全高估了我的能力回答這個問題適當的，所以我希望有更多的知識有更好的解決方案。

來源

2013-02-13 18:12:29

感謝克萊門斯試圖澄清這一點。我認爲從@ServerInterceptor註釋中可以知道攔截器在哪一側被使用。在客戶端閱讀器攔截器的情況下，我期望始終只有0個查詢/路徑參數，因爲只有有效負載被返回。 – 2013-02-14 09:09:49

攔截器肯定會在代碼所在的哪一側生效，但不是'MessageBodyReaderContext'對於服務器/客戶端是不可知的，即使假設傳入的上下文是'ServerMessageBodyReaderContext'也沒有幫助，因爲該類不允許也可以訪問請求。我不得不承認，我不是JBoss專家（甚至不是新手），只是希望其他人出現併發出「我可以做得更好」的任何答案，但到目前爲止這沒有奏效，對不起。 – 2013-02-14 20:24:51

我今天偶然發現了同樣的問題。我需要@PathParam S和@QueryParam S IN的read()方法，結束了這樣的事情：

public class MyInterceptor implements PreProcessInterceptor, MessageBodyReaderInterceptor 
{ 
    private static ThreadLocal<UriInfo> uri = new ThreadLocal<UriInfo>(); 

    public ServerResponse preProcess(HttpRequest request, ResourceMethod method) 
    { 
     uri.set(request.getUri); 
     ... 
    } 

    public Object read(MessageBodyReaderContext context) 
    { 
     String param = uri.get().getPathParameters().getFirst("myidparam"); 
     ... 
    } 
}

雖然現在考慮這個問題的時候 - 我不是很確定，如果只是用PreProcessInterceptor/PostProcessInterceptor也會做我的（也許是你的）問題的訣竅。我明天再看一次。

來源

2013-02-21 20:52:00 carstor

真是個破解！也許PreProcessInterceptor/PostProcessInterceptor是更好的選擇。然而，我不得不弄清楚如何從HttpRequest獲取有效載荷而不干擾請求處理... – 2013-02-26 09:13:57

是否有可能從RestEASY MessageBodyReaderInterceptor中的MessageBodyReaderContext獲取@PathParam或@QueryParam？

回答

相關問題