Seasar2.3その２

仕事先で、今作成中のシステムに試しに入れて色々動かしてみました。特に問題なく動いてるし、たしかに基盤系以外のdiconファイルはいらなくなることを確認。これ入れたらメンバー楽になるだろうなぁ・・・と思ったのですが・・・、自動設定では定義分割機能やネームスペース機能が使えないっぽいと判明。
ネームスペースは、Componentアノテーションでネームスペースを利用してname属性を定義したら何とかなるかなぁと思ったのですが、上手くいきませんでした。定義分割については、FileSystemComponentAutoRegisterが一つのContainerに登録しているので、現状では全部一つの定義に入ってるっぽい。以前自分が自作AutoRegisterを作成したときに、子Containerを漏らさず取得するのに手間取ってしまったのですが、S2.3のAspectAutoRegisterは一つのContainerしか利用せずに問題なく動いてるから不思議に思ってました。自分がFileSystemComponentAutoRegisterをよく見てなかったのが問題だったのですが、実際は自動設定で一つのContainerに設定追加したコンポーネントをターゲットにしてるから、Containerの親子関係を気にする必要が無かったんですね。
が、今のプロジェクトでは業務毎に細かく設定ファイルを分割して運用しようとしていますし、それによって「インターフェイスの実装オブジェクトの重複」に対応する定義ファイルを極力少なくしようと試みています。例えば、ある一部の業務では別システムのデータベースに接続する必要があるので、j2ee.diconに設定しているDataSourceとは別のDataSourceオブジェクトを作成する必要があるのですが、このDataSourceや、それを利用するコンポーネントを共通なdiconファイルに定義してしまうと、これらのコンポーネントに対して自動バインディング定義が使えなくなります。現状では、別DB用のDataSource関連コンポーネントをまず一つのdiconファイルに定義し、そのコンポーネントを利用する業務に対してだけ、分割したdiconファイルの中でincludeして利用しようとしていました。しかし自動設定を利用するとこういうことは出来ないのではないのかな？・・・あ、利用する業務に関してだけ、普通にファイルで定義すればいいのか・・・
うーむ、自動設定を無理に全てに対応しようとせず「利用できるものは利用する」という前提で採用したら上手くいきそうな気もします。・・・が、定義分割することによって安心して自動バインディング機能を使っていたのもまた事実だしな・・・今のところ、現状S2.2系のままで行こうかなと思ってます。
あと、ちょっと話がそれますが、DataSourceオブジェクトを共通なdiconファイルに複数定義してしまい、名前を"j2ee.dataSource"以外にするとS2TestCaseがエラーをおこしてしまうんですね。setDataSourceメソッドが無いので、デフォルトとは別のDBに接続するテストを行う時に、j2ee.diconをテスト用に個別に用意する必要があるのかな？ うーん、ちょっとめんどくさそう・・・
SpringやS2が今後どのような形で設定ファイルレスの方向に進んでいくのか、アノテーションを利用した定義方法を提供していくのか、注目していく必要がありそうです。個人的には、EJB3ちっくなアノテーション利用方法で、開発者が「わかりやすい」形でクラスに機能定義したいし、且つ「EJB3コンテナ」が必要ない環境で簡単に動かせるという機能をDIコンテナに提供してもらうのが一番嬉しいかな？ 以前触ってみた、Hibernate Annotationsみたいな利用方法で、あらゆる機能を利用できるのが理想でしょうか。