SeasarがOSGiをサポートするとうれしいところ

koichik氏からコメントを頂きました。Seasarはほんとにまったく使ったことがSeasarがOSGiをサポートするとどんな人がどううれしいか語れとの事なんで、語ってみます。S2Containerはほとんど使ったことがないため、「違うよ」ってツッコミポイントは多々あると思うんで、そこはジャンジャン突っ込んでください。

Seasar2 で OSGi サポートと言った場合に二つあって，一つは Seasar2 自体が OSGi バンドルの集合体として提供されるということ．WAS6.1 や GlassFish v3 など，AP サーバの OSGi 対応とかこの方向ですね．
もう一つは Seasar2 を利用するアプリを OSGi バンドルの集合体として構築できること．Spring の OSGi サポートはこっちですよね (よく知らないけど)．

って事をおっしゃっていたのでそれぞれ回答していきたいとおもいます。

Seasar2 自体が OSGi バンドルの集合体として提供されると何がうれしい?

Seasar2がOSGiバンドルの集合体として提供されるようになると、Seasar2が依存するライブラリのバージョンと、アプリケーションが利用するライブラリのバージョンの不整合を気にする必要がなくなります。これはたくさんライブラリを利用するような大きなアプリケーションになればなるほど効果があると思います。
脱線しますが、GlassFish v3などのAPサーバーやDBサーバーレベルまで話を拡張すると、単一VM上で複数のサーバーの稼働が可能ですね。WAS6.1についてはWAS6.1上で稼働するアプリケーションとしてOSGi Bundleがサポートされているので、ちょっと違うはずです。

Seasar2を利用するアプリをOSGiバンドルの集合体として構築できると何がうれしい?

OSGiのサポートをDIコンテナ側ですると何がうれしいかって言うと、プラットフォームレベルでEclipseのようなプラグインシステムが手に入るというところでしょう。DIコンテナではXMLなりCoCなりで実行するクラスが静的に固定されてしまいますが、OSGiコンテナ上ではBundleの構成で切り替えられたり、実行するクラスの選択をできるようにできます。
実行時にOSGiコンテナに乗っているBundleの構成によって、アプリケーションの振る舞いが変えられるという点はEclipseユーザーの方には同意いただけると思います。配布されているpluginをpluginsフォルダへ配置するだけでビューだったりエディタだったりを追加することができますよね。それと同様のことができるようになります。
この利点についてもうちょっと突っ込みますね。例えば今自分が作っているPercsというEclipse RCP(Pluginでも動かせます)は今のところATOM/RSSのみがデータソースとして利用できます。ですが、あるインターフェースを持つクラスがOSGiコンテナ上にデプロイされれば、そのインターフェースを介してデータソースを追加できるように設計しています。ちなみにSpringのOSGiサポートではインスタンスの注入対象をSpringのDI Containerで扱うのと同じような形式で書けるようになっています。

ってな感じが僕が感じるうれしい点なんですが、どうでしょうか。