Springのアプリケーションサーバはwithout J2EE。
meanwhile they were mostly using only the web container portion of their appserver. SpringSource as a result wanted to provide a simpler platform based on today's development needs.
http://www.infoq.com/news/2008/04/springsource-app-platform
J2EEに「盛り」すぎた結果、サーバを提供する側も使う側もお腹いっぱいになって、「毎日外食じゃなくてよくね？」みたいな状況が発生、というところでしょうか。実際の所、新しいJ2EEの規格にはあんまり興味がないです。
一番大きな理由は、サーバ側に機能が乗ると、実際に使えるようになるまでだいぶタイムラグがあるということ。
プロジェクトで使うサーバがその規格に則っていて、かつ確実のそのサーバが本番で使えることがわからないと、なかなか手が出せないから。
（政治的な理由で、使うサーバが変わる事はよくある）
それであれば、規格化されていないものでも、アプリに組み込めるもののほうがありがたいと思う。
アプリに組み込めればすぐに使えるし、互換性の心配もないですし。
個人的な意見としては、EJBとかに取り組む前に、Servletの足回りの諸問題に取り組むべきだったのかなと思います。
WebSphereのlog4j問題あたりから言われているクラスローダ問題の標準化とか、web.xml読み込み方法の標準化とか、ソケット周りの挙動とか。
Spring陣営にも、そういうところのモヤモヤ感があったのかもしれない（単にビジネス上の話かもしれないけど）
今後J2EEはプロファイル制度になって、一部だけサポートすればよくなるそうですが、逆にソケット自体をアプリに渡す「ソケットプロファイル」みたいなのもあってもいいのかもしれないと思います。アプリケーションサーバは、クラスタリング、アプリの監視、セッション管理、トランザクション管理だけして、リクエストのパース部分からアプリに任せてしまう。もちろんそれだけだと大変なので、パースとかJSP処理とかはライブラリとして提供する、みたいな。これならアプリがサーバに依存する部分が少なくなるので、新しい機能がでてもアプリ側に入れて使えるし、アプリケーションサーバのベンダーも最新機能を追う必要がなくなるし、みんな幸せなんじゃないかな。
と妄想してたら頼んでいたパソコンが届いたのでもうどうでもよくなった。やっぱりMini-ITX最強。
