home ホーム search 検索 -  login ログイン  | reload edit datainfo version cmd icon diff delete  | help ヘルプ

Java/JAX-RS/Jerseyで、FilterからResource Classに値を渡せるか

Java/JAX-RS/Jerseyで、FilterからResource Classに値を渡せるか

Java / JAX-RS / Jerseyで、FilterからResource Classに値を渡せるか
id: 1351 所有者: msakamoto-sf    作成日: 2015-02-12 01:17:24
カテゴリ: 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におけるサーバサイドセッションを使うことの是非については、個人的には 技術/HTTP/REST設計思想の "Stateless" との付き合い方 にて現実優先の結論を出しており、無理に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)



プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2015-02-12 01:19:28
md5:4f2b799e11feef31dfa3aac7919a3ffb
sha1:7fe56a9115f2abe46d2067fe09acb795ac32dc0d
コメント
コメントを投稿するにはログインして下さい。