Seasar2.4のCool Deployを試す。

Seasar2.4からは既存のComponentAutoRegisterに加えてHot Deploy＆Cool Deployが自動登録機能に加わるみたいで、早速試してみました。（ちなみに、S2TopLink関連で自分がS2.4の最新の自動登録機能を確認したいが為に試してますので、あまり機能の説明には気を使ってない文になってます。）
まずはCool Deployから。
ComponentAutoRegisterのときは、検索するリソースパスに存在するクラスを１つ指定することによって、検索開始するルートを決定していました。例えば・・・

	<component class="org.seasar.framework.container.autoregister.ComponentAutoRegister">
		<initMethod name="addReferenceClass">
			<arg>@example.entity.TestA@class</arg>
		</initMethod>
		<initMethod name="addClassPattern">
			<arg>"example"</arg>
			<arg>".*DaoImpl"</arg>
		</initMethod>
	</component>

こんな感じで設定すれば、addReferenceClassで登録したクラスと同じパス上（ファイル・Jarを問わず）のクラスが検索され、addClassPatternで指定したパターンに合致するクラスが自動登録されていました。
対してCoolDeployでは、Cool Deploy機能を設定したdiconファイルへのパスを利用してルートを決定してるみたいですね。上の例をCool Deployで定義するときは・・・

	<component class="org.seasar.framework.convention.impl.NamingConventionImpl"/>
	<component class="org.seasar.framework.container.cooldeploy.creator.DaoCoolCreator"/>
	<component name="project" class="org.seasar.framework.container.cooldeploy.impl.CoolProjectImpl">
		<property name="rootPackageName">"example"</property>
	</component>
	<component class="org.seasar.framework.container.cooldeploy.CoolComponentAutoRegister">
		<initMethod name="addProject">
			<arg>project</arg>
		</initMethod>
	</component>

Seasar2のテストケースを見ながら真似て作ってみたのですが、これで動きました。CoolCreatorインターフェイスによってクラスパターン定義が行われているみたいで、DaoやLogicやAction用など、基本的なクラスパターンは既に作成されています。それらの中から登録したいパターンのクラスをdiconファイルに設定してやれば、自動的に登録されるみたいです（上の例ではとりあえずDaoのパターンだけ登録しています）。ComponentAutoRegisterのときには、クラスパターンを自作していたのに対して、2.4ではデフォルトの設定パターンがあらかじめ用意されるようになるってことですね。更に実際のクラスパターン名については、NamingConventionというインターフェイスの実装により一括して定義出来るようです。
（※余談ですが・・・CoolProjectImplを見ていて気づいたのですが、同一インターフェイスを実装したクラスを複数登録した場合、そのインターフェイス配列を受け取るsetterを使うことによって、登録した複数コンポーネントを自動的にDI出来るようになったんですね。同じことを以前の自分は、S2ContainerのfindComponentsメソッドを使って、設定ファイルや@Binding上で定義していました。これが自動で出来るようになると、複数の実装を使い分けるようなときに、実装を後から追加するような処理がより簡単に作れそうです。）
今回Daoで試してみたのですが、Daoの場合インターフェイスだけでComponentに自動登録される（S2Daoを意識してるのかな？）みたいなので、同一パッケージの直下にimplってパッケージを作成し、その中に実装クラスを入れたら、そのクラスが自動登録されるようになりました。インターフェイスと同じパッケージに実装クラスを入れたりしてると認識されないみたいなので、注意が必要です。つまり今回の機能は単なる自動登録定義の雛形というだけではなく、パッケージやクラス名定義の規約にもなり得るってことですね。
複数のパスを設定したいときはどうするんだろうと一瞬思ったのですが、パス毎にdiconファイルを用意して、そこにCool Deployの設定を書けばいいのか。なるほど・・・
2.3のときは、自動登録したいクラスのパッケージ名やクラス名パターンを定義することによって、AutoRegisterにクラス検索させていましたが、2.4では、基本となるパッケージ名を登録しさえすれば、後は基本的なクラスの命名定義があらかじめ用意されているので、そのクラスを利用すれば一気に自動登録パターンを設定することが出来るみたいです。実際にプロジェクトで開発を行うときには。当然ルートとなるパッケージ名を決めるし、クラスの命名規約も決めるから、それをS2.4があらかじめ定義しているクラス名パターンに合わせれば、それだけで設定が自動化される・・・ってことかな？
ちょっと気になったのが・・・

example.pg1.dao;
example.pg1.logic;
example.pg2.dao;
example.pg2.logic;

・・・みたいなパッケージ編成にするときは、どうしたらいいんだろう？というわけで、設定ファイルは上の例のままで、複数のDaoクラスをパッケージを分けて作成して試したところ・・・問題なく自動登録されました。なるほど、ルートのパッケージ名と規約で定義されたパッケージ名との間に個別のパッケージ名を挟んでもOKということか。これは便利そう・・・
（追記）ひがさんからコメントいただきました。上の例の場合、「example.pg1」「example.pg2」と２つのプロジェクトを登録するのが正しいみたいです。実際設定してみましたが、CoolCreatorの設定はそのままで、プロジェクトの部分のみを固定で登録すればいいみたいですね。
あと、Aspectはどこで定義するんだろうと思っていたのですが・・・ComponentCustomizerインターフェイスを利用するみたいですね。CoolCreator毎に定義出来て、chainも可能みたいなので、AspectAutoRegisterで出来た定義は全て利用できるみたいです。
EJB3を実装したアプリケーションサーバの場合は、コンポーネント（というかSessionBean）を@Stateless等のアノテーション検索によって登録しているっぽい（NetBeans5.5+GlassFishでEJB3作成を試したときは、自動で登録されていました）のですが、CoolCreatorの仕組みを利用すれば、比較的簡単にアノテーションによる自動登録も出来そうな気がします。ただ、Seasar2.3を使って開発したときは、ComponentAutoRegisterのパターン定義を色々修正することによって、全体のクラス登録をコントロール出来たのが非常に便利でした。アノテーションで登録対象を定義する前に「命名規約」によってコントロールする手法は、自分が一度開発で利用した経験からも、非常に有効ではないかと思っています。