s2container.diconのコンテナは独立系？

# koichik 『AspectCustomizer の interceptor プロパティを String の interceptorName に変更しました．これにより，Interceptor は s2container.dicon ではなく，app.dicon (相当) のコンテナからルックアップされるようになります．

うーん。なんだかよくわからなくなってきました。
s2container.diconの位置づけがいまいち理解できてないです。

s2.3までは、コンテナはinclude関係に対応したapp.diconをルートとしたツリー構造をとっていたわけですよね。
で、s2container.diconとその構造の関係はどうなっているのでしょう？完全に独立している？それとも、app.diconの上位コンテナがs2container.dicon？

AspectCustomizerを仕掛ける対象のコンポーネントAがs2container.diconのコンテナαに管理されているとすれば、そのコンポーネントAに対する依存関係を解決するためのコンポーネントB(=interceptor)はs2container.dicon自身かまたはその下位コンテナから探してくるわけですよね。これはコンテナαがそのようにがんばると。
interceptorコンポーネント自体をプロパティで明示的にバインドした場合はそのように動作するんだったような気がします。

で、それが正しいとして、じゃぁStringのinterceptorNameで依存関係を間接的に定義したらどうなるのか？
えーと、AspectCusomizer自身がSingletonS2ContainerFactoryでapp.dicon系列のルートコンテナを取得して、そこから指定されている名前のinterceptorを取得して、それを利用するようになる。ってことですか。あ、なんとなくかみあったような。
＃SVNダウン中のため、裏が取れず(^^

この流れから逆算すると、s2container.diconのコンテナは独立系と推測できそうです。
app.diconの上位コンテナに位置づけられているのだとすれば、そういう小細工(?)なしで普通にapp.dicon系列のコンテナからコンポーネントを取得できますからね。

なんて、想像に妄想を重ねて群盲なんとやらな状態ですね。
ソースを追ってきちんと読み込めば確実なんですが...。

アプリケーションのコンポーネントは s2container.dicon には記述しない方向で考えています．なので，肥大化の心配はあまりないはず．』

これは下でかいたようなやりかたは推奨されないようになるということでしょうか。
「方向」ということなのでまだそういう書き方はできないような雰囲気ですが、そのうち情報が出てくるのですかね。
ためしにapp.dicon系列のallpage.diconやalldao.diconなどにOndemandBehaviorなコンポーネントを分散記述してみましたが、普通にエラーになっていました。(エラー内容はメモしてませんでした)
そういうことではない？