2013-05-01 42 views
0

本質上,我有一個MessageBodyWriter將對象寫爲JSON,我希望能夠根據哪個資源方法處理請求來控制輸出的某些方面。但是,@Provider類的默認生命週期是單例(每個JVM一個),所以我不能注入某個配置對象的實例。這給我留下了2個明顯的解決方法:如何在每個請求的基礎上配置JAX-RS MessageBodyWriter?

  1. 使用自定義的註釋:對的writeTo(...)每個調用包括被調用的方法註釋的名單,所以我可以檢查一些存在註解。但是,JAX-RS方法已經非常適合元編程。
  2. 使用ThreadLocal屬性映射:假設每個線程有一個請求,但是這種方法會破壞封裝。資源方法需要注意到有一些其他課程在尋找這張地圖。

有沒有辦法改變提供程序本身的生命週期?我正在使用澤西島。

回答

1

JAX-RS 1.1規範requires that implementations support singleton providers and allows support for other lifecycles但沒有建議沿着這些線路的任何其他內容。據我所知,純澤西不支持單身之外的任何東西。使用the jersey-spring contrib module,您將得到對使用Spring作爲Jersey的IoC容器(從中獲取其資源和提供程序實例)的支持。我知道Spring支持多種生命週期,包括請求,但是我不確定是否支持這種生命週期是建立在球衣彈簧中的。

2

不確定爲什麼您需要每個請求基礎的MessageBodyWriter提供程序。如果你只是想區分哪些方法是用JSON輸出的,哪些不是,那麼jersey-json已經支持。

儘管@Provider是單身人士。你仍然可以像下面一樣使用每個請求對象。

@Provider 
public class StViewProcessor implements ViewProcessor<ST> {  

    ...... 

    @Context 
    HttpServletRequest request; 


    public void writeTo(ST st, Viewable viewable, OutputStream out) 
      throws IOException { 
     System.out.println(request.getRequestURI()); 
     ... 
    } 


} 

如果您想要爲每個請求注入實例,可以查看PerRequestTypeInjectableProvider。這是關於它的link

+0

爲了澄清,它沒有區分JSON和非JSON,而是如何格式化JSON,或者過濾它。因此,最終同一位作者參與其中。使用請求對象與ThreadLocal屬性非常相似,但有趣的是每個請求上下文將在每個請求(不知道)上正確注入。 – Shaun 2013-05-02 17:56:27

+0

是的,使用'@ Context'的每個請求對象都基於線程本地代理。所以你不需要實現你自己的ThreadLocal屬性映射來做同樣的事情。 – Willy 2013-05-03 02:03:23

相關問題