EJBを使ったJavaのなんたらシステムが起動した後に、中のEJBが安定するまでの時間は運用してみないと誰にも判らない。
と云うのも、ヤベーと誰かが気が付いて、実装クラスのインスタンスをインタフェースの変数にインジェクションするからだ。
云ってしまえば、インタープリターのごとき仕業であるので、遅いの一言に尽きる。
EJBを使えばjUnitでmockが便利なんて詭弁でしかない。
大体、mockのソースの賞味期限は数か月にも満たないのが普通で、
そんくらいなら、Eclipseで、src/main/javaとsrc/test/javaのクラスパスの順番を変えるくらいで十分だし、その為だけにjUnitのテストソースからプロセス起動するようなことをしてもよいだろう。
※当時の言い分： EJBが出来た頃はEclipseなぞ無く、エディタ＋Shell＋吐き出されるログが全てだったので、環境変数のクラスパスを手で変更するのは大変危険だった。
とあるよく使うDaoなりActionなりをEJBで作り、jUnitでテスト環境を作ったとしよう。
それをベースに１０～２０個のコピペのようなものは、非常に簡単にできる。
しかし、
本当の地獄はその後に始まる。
Daoに何か変更が入ると、上記のコピペに一斉に修正が必要になる。
１０個ならマシだが・・・１００個だったら、結構大変だ。
そして、
当然の帰結として誰も誰も使わなくなり、
更に数か月が過ぎると、全く使い物にならないjUnitソースの残骸が残るだけなのだ。
無論、プロジェクトの立ち上げ時には非常に役に立つ。
但し、その後は捨てるものだ。
最後に残るのはEJBで作ったDaoやAction
どうやってテストするんだろうね？
え、実際に画面を実行？
です。（キッパリ
だって、その方がちゃんとしたテストデータもテストケースもあって、役に立つんですからね。
ここに到達してしまうと、
jUnitなんてもう使う訳もない。
※当初の仕様から全く変わっていないものを除く。
別に、直接Daoオブジェクトを作っても何も支障が無いことに気が付くわけである。
Actionだって、httpセッション経由で起動をかけることだって、別に難しい訳でもない。
それでも、今なおEJBは生き残っている。
理由はいたって簡単、
大半の機能を使うこともないlog4jを何となく使ってしまうのと同じなのだ。
多分、Java系の定番jarファイルを使うのを止めたら・・・
別世界なんだろうな。（大笑