AOPの実装方法

(from J2EE Development without EJB)

ダイナミックプロキシ
  • J2SE標準なので他のライブラリが不要
  • 副作用がなさそう
  • インターフェイスでなく、クラスのプロキシは作れない(でも普通プロキシかけるのはインターフェイスだから別にいいかも)
  • パフォーマンスの点でリフレクションコストがかかる(J2SE1.4以降早いから、よっぽどクリティカルな頻度で呼ばれるアドバイスでなきゃ別にいいと思う)
  • Nanning、Spring(インターフェイスに対するプロキシ時)で利用されている
動的バイトコード生成
  • クラスにもプロキシが可能
  • メジャーなライブラリはCGLIB、Javassistなど
  • CGLIBはSpring(クラスに対するプロキシ)、Hibernate2、Seasar2で利用されている
  • Hibernate2でAPサーバ上で広く利用されてたから多分問題なく使える
ソースコード生成
  • EJBのスタブ生成などはこの方法が主流(現在はどうだろう?)
  • この方法は最近人気が廃れ気味。他の方法の方がシンプルだから。
カスタムクラスローダーの利用
  • 特定のクラスのインスタンス全部にプロキシしたいとき
  • DIコンテナからひっぱってくるインスタンスでなく、newで作るインスタンスにもプロキシ可
  • 環境まわりで不安。APサーバ上によっては、何か問題がないとも限らない。APサーバ自身がクラスローダー階層を制御してるので
  • というかAPサーバがクラスローダの切り替えオプションを提供してないとできない。APサーバ起動で細工すればできるかもしれないが、ますます環境面で不安。
  • 現状、個々のWebアプリ向けのAOP技術というよりAPサーバの実装向けのAOPか?
  • JBossAOP、AspectWerkzはこの方法
言語拡張
  • Java言語自体を拡張する方法
  • 最もなんでもありの方法
  • 新しい言語をおぼえる必要があり、他の方法に比べて複雑かも
  • AspectJがこの方法


分類がちょっと並行してませんが。カスタムクラスローダーの利用で、プロキシには動的バイトコード生成するというパターンもあるし。


AspectWerkzはクラスローダーベースのAOPってどんな設定でできるのか?簡単だとおいしいな、と思ったが、やっぱり、APサーバー側の環境設定は必要な模様。
http://docs.codehaus.org/display/AW/How+to+integrate+Aspects+in+J2EE+apps+with+aop.xml
いや、システムクラスパス通すだけか?どうだろう。