#navi_header|Java| Java/JAX-RS/Jerseyで、FilterからResource Classに値を渡せるか イメージ的には、認証系のFilterでHttpSessionからドメインクラスのインスタンスを取り出して、Resource Classに"@Context"か"@Inject"で注入できたらなぁ。 →結論:ストレートにFilterからResource Classに渡すことは多分できない。ただし、FilterからHttpServletRequestにインスタンスを設定することは出来るため、RequestScopeでCDIのProviderを用意して、Resource Classへの注入はFactory側で HttpServletRequest を参照、Filter側でドメインクラスのインスタンスを取り出して HttpServletRequest に設定、みたいなアプローチは多分取れそう(未検証)。 そもそも、FilterとResource ClassではLifeCycleが違う。Resource ClassはRequestごとにインスタンスが生成され、Filterはアプリケーション単位で生成される。 Resource Classに "@Inject" できるということは、それは RequestScope になる。 しかし、FilterはRequestごとにインスタンスが生成されないため、Filterに "@Context" で HttpServletRequest を注入することはできない。 Filterの filter(ContainerRequestContext requestContext) で、ContainerRequestContextに getProperty()/setProperty() がある。 これを使って、Filterの方で HttpServletRequest -> HttpSession -> 認証情報や現在のステートを保持するドメインクラスの取り出し -> ContainerRequestContext#setProperty() (= HttpServletRequestにセット) -> Resource Classへの注入時に、RequestScope な Factory で "@Context" で HttpServletRequestを注入し、そこから Filter がセットしたドメインクラスのインスタンスを取り出し、Resource Classに最終的に注入。 ・・・できるかな・・・? なお、"@Inject" の使用自体は、JavaEE6以降のCDIの採用で、GlassFish側でもCDIとJerseyの相互連携が取れるようになったので、仕様上問題なく、思想的にもJavaEEの枠組みに収まっていると思う(こんなこと考える事自体がもう厭になってくる)。 よって、"@Inject" を効果的に使い、HttpSesssion にまつわる煩雑かつコピペの多いコーディングを減らすのは、合理的な判断であると思う。 また、"stateless"を重視してサーバサイドセッションを使わない方針のRESTにおいて、HttpSession=Servletにおけるサーバサイドセッションを使うことの是非については、個人的には [[1350]] にて現実優先の結論を出しており、無理にRESTに従う必要はなく、枯れたサーバサイドのセッション管理機構を採用するという判断は十分に合理的であると考える。 Resource Class と Filter のLife Cycle 参考: Resource Class : リクエストごと。 >3.1.1 Lifecycle and Environment >By default a new resource class instance is created for each request to that resource. First the constructor (see >Section 3.1.2) is called, then any requested dependencies are injected (see Section 3.2), then the appropriate >method (see Section 3.3) is invoked and finally the object is made available for garbage collection. >An implementation MAY offer other resource class lifecycles, mechanisms for specifying these are outside >the scope of this specification. E.g. an implementation based on an inversion-of-control framework may >support all of the lifecycle options provided by that framework. Filter : アプリケーションで一個。 >6.4 Lifecycle >By default, just like all the other providers, a single instance of each filter or entity interceptor is instantiated >for each JAX-RS application. First the constructor is called, then any requested dependencies are injected, >then the appropriate methods are called (simultaneously) as needed. Implementations MAY offer alternative >lifecycle options beyond the default one. See Section 4.1 for additional information. 出典 : JAX-RS: Java(TM) API for RESTful Web Services (Version 2.0 Final Release, May 22, 2013) #navi_footer|Java|