2014-04-23追記
昨今の状況を鑑みるに、新規案件でのStruts2の採用は余りお勧めできないと言わざるを得ません。
僕はStruts2およびOGNLのソースコードを実際に読み込んだ上で、自分で危険と判断したところは独自でパッチを当てているため、報告されているような脆弱性に対して、最初から耐えられるようになっています。
そもそも、OSSを採用するというのは、そういうことですし。
ただし、新規案件でそのような運用を最初から織り込むのは正しい判断とは言えないでしょう。
Struts1.xがEOLになりました。お疲れ様でした。
5年ほど更新が無かったので、やっと正式にEOLかという思いです。
さて、国内における一定規模以上のWebシステム構築では、ベンダーお抱えの『フルスタック型Webアプリケーションフレームワーク』を使うことが前提になります。NTTデータ系列ならTerasolunaとか。
で、その手のフレームワークは大抵、作られた時代がちょうどStruts1.xの旬であったことから、Sturts1.xがベースになっています。
それからおよそ10年弱、Struts1.xはそれこそ骨の髄までしゃぶる勢いで魔改造が加えられていった結果、ソースコードの隅々まで研究され尽くしてきたわけです。
RequestProcessorのソースを解析して激しく拡張するとか、昔よくやったわーという懐かしさを覚える方も多いでしょう。
さて、どうすんの？
これから各ベンダーが取りうる作戦は以下の2つかと。
おそらく現実的なのは、以下の理由により1.でしょう。
- そもそも2008年以来ずっとそうしてきたのだし、これからも現状維持すれば良い
- Struts1.xで動く業務システムは星の数ほどあり、そいつらの保守を切れるわけが無い
- 隅々まで研究され尽くしたStruts1.xの保守はぶっちゃけカンタン
- 国内のコーダーは、JavaでWeb開発を経験した人の大半はStruts1.xの経験しか無い上、そもそもStruts1.xで何ら困ってはいない
- （少なくとも、僕が活動している領域ではそういう話ばっかりです）
しかしEOLになった製品をこれからも新規案件で使い続けるのはヤダ！という方もいるでしょう。
じゃあ乗り換えるとしたら選択肢は何なのか…？という話になるわけですが、僕はStruts2をオススメします。
洗練された最高のフレームワークだ！と言うつもりはありませんが、
- Struts1.xの正統な後継製品である
- スーツたちを説得する際、こういうのはバカにならない
- 開発のワークフローが概ね同じ
- 「アクションフォームを作って、アクションクラスを作って、JSPを書いて…」という流れを変えなくて良い
- convention pluginを使えば設定ファイルをほとんど書く必要が無い
- 国内では比較的少数だが、世界的に見ればユーザー数は多い
- すなわち、長期間のサポートが期待できると考えて良い
という特徴があります。Web上での評価は少々芳しくないようですが、Struts1.xの移行先として捉えるなら悪くない選択肢のはずです。
各種Webフレームワーク比較は色々とありますので、詳しくはググってください。
なお、いくら正統な後継とは言え、Struts1.xに依存しているコードは全部捨てる覚悟が必要です。
