日々の破片

_ クロスとつくと、大抵、厄介が舞い込む

TomcatのCrossContextを使ってみようと考えた。

/aと/bは互いに異なるコンテキスト（しかし同一JVMを利用している）。

歴史的諸事情からclasses/hogeが、/a/WEB-INF/classes/hogeと、/shared/classes/hogeで重複している。

この状態で、/a、/b基本的に、問題なく動いている。

ここで、/aから、ServletContextの属性に、hoge.xを突っ込んむ。なおhoge.xは、hoge.h.xインターフェイスを実装している。

/bで、getServletContext().getContext("/a")して（これをやるには、server.xmlのContextタグにCrossContext="true"を付けてやる必要がある)/aがServletContextの属性に設定したhoge.xのインスタンスを取得する。

この状態、/bで取得したオブジェクトは、

System.out.println(o); --> hoge.x#3476

とかになる。そりゃそうだろう。

しかし、o instanceof hoge.h.x はfalseになるし、

hoge.h.x x = (hoge.h.x)o;

は、ClassCastExceptionで飛ぶ。

仮説1)そういうもの。コンテキストが異なれば、obj.getClass().equalsが偽となる（そりゃ、確かにクラスローダが異なる）

仮説2)そういうもの。しかし、クラスローダがどちらもWEB-INF/classesローダまたはsharedクラスローダで合致していれば問題ない（この場合、位置から見てもローダが異なる）

仮説3)そんなことすることがバカ。コンテキストをまたがった場合は、リフレクションを利用してリモートプロクシ作ってやる必要がある。（.netのクロスAppDomainはこれだな）

仮説4)インターフェイスはそうだが、クラスは特別にうまく動く仕組みだ。

仮説5)CrossContextを認めるだけでなく、さらにセキュリティ設定が必要(たとえば、Classのインスタンスが異なるのは当然としても、==でチェックかequalsでチェックかとかが変わるとか。っていうか、equalsの実装はどうなってんだろう？ ==と同じだから、これは違うか)。

仮説6)CrossContextは、問題があるので使うべきではない。（確かに一理ある。バージョンが異なる場合とか。それで気付いたが、.NETで複数バージョンを利用した場合も、リモーティングはやばそうだな）

仮説7)とりあえず、2週間は放っておいて、同一コンテキストで動かせ。これは仮説じゃないな。

#ゴルゴダクロス（タイガーマスク）

_ 正解

仮説2。ただし、両方をsharedに統一。両方がWEB-INF/classesの場合は、なんとなくだめそうな気がするがそこまで試す必要がないので、ここまで。