Struts2を好きになれない点
Struts1に代わる次世代のWeb MVCフレームワークとしてStruts2に対する期待が大きいようです。この傾向はあまりプログラミングをしない層の方で特に強いようですが、プログラマーの中でも勉強されている方も多いようです。Struts1に対する移行先としてJSFとStruts2が比較検討の候補としてあげられる場合も多いようです。技術的な詳細をあまり理解していない方々は、おそらくStrutsというブランド名から、実績面や過去の資産との互換性、開発者のスキル面などで有利なのではないかというように考えられる場合が多いですが、もちろん実態はWebWork2にアノテーションやCoCを取り入れたものであり、従来のStrutsとはほとんど互換性のないフレームワークです。私も少しは勉強してみたのですが、Struts1よりはぜんぜん便利なのは確かですが、Spring MVCなどの他のアクションベースのフレームワークと比較して、個人的にはあまり魅力を感じていません。*1今後大幅な改良があれば別でしょうが、今のところStrutsの後継フレームワークとして次世代のデファクトとなることはないという気がしています。Seamのような会話管理サポートが非常に弱いことやアノテーションなどの使い方がいけていないといったプログラミングモデルの問題もありますが、一番問題と思うのはJavaEE 5の標準と相性が非常に悪いとことですね。少なくともアーキテクチャー上以下の問題があります。
- Struts2のタグライブラリはOGNLという独自の式言語に強く依存しているため、JSP2.1のUnified ELとうまく共存できない。JavaEE 5以降のサーブレットコンテナーでは明示的にUnified ELを無効化するなどの対処が必要。(http://struts.apache.org/2.x/docs/why-do-i-get-a-javaxelelexception-when-using-ognl-with-jsp21.html)
- サーブレットがなく全てフィルターからディスパッチするアーキテクチャーであるが、フィルターからJTAやEJBなどのグローバルトランザクションに依存するサービスを呼び出すことは本来は規約違反であると考えられること。（JavaEE SpecEE 4.2.1参照）
後者の問題により厳密にはTomcatなどの非managedな環境でなければJavaEE 準拠とは言えなくなります。実際上は、なんとなく動作してしまうケースがほとんどでしょうが、ベンダーのサポートなども考えると問題かと思います。
