ServiceCreator

Kijimuna

Seasar 2.4リリース! 今更でも恥ずかしくない、始めてみようDIプログラミング SMART deploy 編のサンプルの場合の完成イメージ図。

SeasarからNamingConventionImpl,ServiceCreator,ComponentCreatorImplあたりを引っ張ってきて、
テキトーにコンパイルエラーになる部分のコードを消していったら、なんとなくできた。

問題はルートパッケージの扱い。
Kijimunaはdiconファイル１つに対してハンドラ（DocumentHandler）のインスタンスを１つ対応させて解析している模様。
現状のままだとcreator.diconの解析中にconvention.diconのルートパッケージはわからないので、
何が登録されているコンポーネントか判断できない（includeされているdiconファイルは別ハンドラで解析している）。
ComponentAutoRegisterだと１つのdiconファイルに全部情報があるからいいんだけど。

常にconvention.diconが最初に解析されるならDocumentHandlerのstaticフィールドにルートパッケージを持たせるとか
あるが、そうじゃないだろうしな。

うーむ、（変更があろうが無かろうが）常にconvention.diconを最初に解析するようにすればいいのかな。

ちょっと考えます。

追記：
っていうか、ServiceCreatorで登録されるコンポーネント（上記の例だとprintServiceとmessageService）って、
ルートコンテナ（app.dicon）に登録されるのか。じゃあcreator.diconじゃなくてapp.diconを表示したときの
アウトラインページにprintServiceとmessageServiceが無いとだめジャン。とほほ。