Seasarファウンデーションは2005年11月8日，DI（Dependency Injection）コンテナ「Seasar2」の新版である「Seasar2.3」をリリースする。メジャーなDIコンテナであるSpring Frameworkや従来のSeasar2では必要だったXMLによる設定ファイルが不要なのが特徴。

　設定の記述量を減らすため，Rubyで記述されたフレームワーク「Ruby on Rails」が提唱している「Convention over Configuration」という考え方を取り入れた。DIコンテナの利用者（アプリケーション開発者）があらかじめ決められた規則に従うことで，設定を省略するという考え方である。Seasar2.3では，コンポーネントを自動登録できるようになった。クラス名が「Impl」で終わっているクラスがあれば，実装クラスとしてDIコンテナに自動登録する。

【訂正】 当初の記事では「Seasar2.3では，まず，プロパティの型をインタフェースで自動的に定義できるようになった。DIコンテナの中にインタフェースを実装したオブジェクトが一つあれば，あとはそのインタフェースで自動的にプロパティの型を設定する。」とありましたが，これはSeasar2が従来から持っている機能でした。おわびして訂正します。

　自動設定がうまくいかない場合のために，アノテーションを使ってコードに設定を埋め込むこともできる。ただし，「アノテーションも設定であることを忘れてはいけない。設定が増えると間違いも増える」とSeasar2のチーフ・コミッタである比嘉康雄（ひがやすを）氏は指摘する。基本は「設定ゼロ」である。

　比嘉氏は，Seasarの「All-in-One構想」も明らかにした。DIコンテナであるSeasar2（S2Container）に加え，Webフレームワークである「Teeda」，O/Rマッパーである「Kuina」を用意する。TeedaはJSF（JavaServer Faces），KuinaはJava EE 5のPersistence APIをそれぞれ独自に実装するもの。これら二つのソフトを2006年3月までにリリースし，2006年4月からAll-in Oneソリューションとして提供する。比嘉氏は「『リリース予定』ではなく必ずリリースします」と決意を語った。

　オープンソース・ソフトを利用する場合，Webフレームワーク，DIコンテナ，O/Rマッパーに別々のものを使う場合が多い。例えば，WebフレームワークはStruts，DIコンテナはSpring，O/RマッパーはHibernateといった具合である。しかし「別々だと仕様の穴ができるおそれがある。またトラブルが起こった場合，どのソフトが原因なのか特定するのが難しい。バージョンの違いで動かなくなるといった問題が出ることもある」（比嘉氏）。こうした問題を避けるために，統合ソリューションとして提供することにした。ユーザーにとっては，フル機能がそろっているためすぐに利用できるというメリットもある。

　実は比嘉氏は，8月頃にはO/RマッパーとしてHibernateの次期版であるHibernate3を使うつもりだった。ところが，その後「ユーザーが求めているのはホット・フィックス（迅速な不具合の修正）であることがわかった」という。他で開発されたものを利用していては，ホット・フィックスを提供できない。そこで，現在Seasar2で用意しているO/RマッパーであるS2DAOをベースにPersistence APIを実装する方針に転換した。

　Webフレームワークも同様である。従来のSeasar2でJSFを利用するために用意しているS2JSFでは，オープンソースのJSF実装であるMyFacesを利用していた。これも独自実装に切り換える。JSFの実装は「現在，ある開発者が作っているところ」（比嘉氏）だという。