Seasar2のサポートはいつ終了しましたか？

2016年9月26日です。それ以降、Seasar2本体およびSAStruts・S2JDBCなどの関連プロダクトについて、脆弱性が見つかっても修正は行われません。サポート終了からすでに10年が経過しています。

Seasar2で動いているシステムを今すぐ移行する必要がありますか？

外部公開されているシステム、個人情報や決済を扱うシステムでは優先度が高くなります。社内限定のシステムであっても、Javaランタイムの更新や周辺ミドルウェアのサポート終了に連動して、いずれ稼働環境そのものを維持できなくなります。期限を決めて計画的に進めることをお勧めします。

SeasarからSpringへの移行とシステム刷新はどちらが適していますか？

フレームワークだけを入れ替えるSpring移行は、画面や業務ロジックの構造がそのまま維持できる場合に有効です。一方で、Struts 1やJSPなど他のサポート終了済みコンポーネントが同居している、稼働から15年以上が経過して仕様が把握できていないといった場合は、アプリケーション全体をモダンな構成へ刷新するほうが結果的に総コストを抑えられることがあります。

Seasar2はサポート終了から10年：SAStruts・S2JDBCで作られた業務システムの現在地

Seasar2は、2016年9月26日にサポートを終了しました。本稿の時点で、ちょうど10年が経過したことになります。

それでもなお、Seasar2とその関連プロダクトであるSAStruts・S2JDBCで構築された業務システムは、国内で数多く稼働し続けています。2000年代後半、Seasar2は国産のJavaフレームワークとして広く採用され、会員数百万規模のサイトや複数拠点にまたがる業務システムでの導入実績がありました。当時に構築されたシステムの多くが、現在も現役です。

「動いているから問題ない」で済まなくなる理由

Seasar2で動いているシステムに、いま明確な障害が出ているとは限りません。むしろ安定して稼働しているケースのほうが多いはずです。だからこそ後回しにされてきました。

ただし、サポートが終了しているということは、次の状態にあるということです。

脆弱性が見つかっても修正されない。 公表されるかどうかにかかわらず、対処の手段がありません。
周辺環境の更新に追従できない。 Javaランタイム、アプリケーションサーバ、OSのバージョンアップに際して、動作を保証する主体が存在しません。
実装を理解できる技術者が減り続ける。 Seasar2を実務で扱った経験のある技術者は、新たに増えることがありません。

3点目が、実務上はもっとも重い問題になります。システムが壊れたときではなく、それを直せる人がいなくなったときに、はじめて問題として認識されるからです。

典型的な構成

国内でSeasar2が使われている業務システムは、おおむね次のような組み合わせになっています。

コンポーネント	役割	状況
Seasar2	DIコンテナ・AOP	2016年9月26日サポート終了
SAStruts	Webアプリケーションフレームワーク	Seasar2に依存
S2JDBC	データベースアクセス	Seasar2に依存
Apache Struts 1系	併用されている場合がある	2013年4月サポート終了
JSP / JSTL	画面	構成による

注目すべきは、サポート終了済みのコンポーネントが複数積み重なっている点です。Strutsの対応を検討したところ、その下でSeasar2も同じ状態にあることが判明する、という順序で問題が発覚することも少なくありません。

Apache Strutsのサポート終了と2026年に公表された脆弱性については、別記事で扱っています。

移行の選択肢

Spring Frameworkへの移行

もっとも一般的な移行先です。DIコンテナとしての考え方が近く、S2JDBCからSpring Data JPAやMyBatisへの置き換えも定石があります。画面構成や業務ロジックの構造を維持したまま、基盤だけを入れ替える方針が取れる場合には有効です。

ただし、SAStrutsからSpring MVCへの移行はアクション定義や画面遷移の書き換えを伴い、機械的な置換では完了しません。また、この移行で解決するのはフレームワークの部分だけです。JSPで作られた画面や、Struts 1系が併用されている部分は別途検討が必要になります。

アプリケーション全体の刷新

フレームワークを追いかけるのではなく、システムそのものを現行の技術スタックへ移行する方法です。

次のいずれかに該当する場合、こちらのほうが現実的です。

サポート終了済みのコンポーネントが複数混在している
稼働開始から15年以上が経過し、構築当時の担当者が在籍していない
仕様書が現行システムに追いついておらず、コードが唯一の正確な仕様になっている
画面が古く、スマートフォンやタブレットでの利用に対応できていない

移行規模は大きく見えますが、サポート終了のたびに発生する対応を繰り返さずに済むため、長期で見ると総コストが下回ることがあります。

仕様が残っていないシステムをどう移行するか

Seasar2世代のシステムでもっとも多い課題は、正確な仕様が残っていないことです。構築から十数年が経ち、改修が重なり、ドキュメントは初期のものしかない。結果として、コードだけが唯一の正確な仕様になっています。

この状態で人手による再実装を行うと、長年の運用で積み上がった例外処理や業務ルールが移行の過程で失われます。稼働後になって「以前はできていた処理が通らない」という形で表面化し、収束までに時間がかかります。

日本ビビファイでは、既存のソースコードを解析してシステムの構造と業務ロジックをモデルとして抽出し、そのモデルから新しいアプリケーションを生成するモデル駆動型のアプローチを採っています。人が読み取って書き直すのではなく、構造として引き継ぐ方式です。

さらに、移行後のシステムが移行前と同じ動作をすることを自動テストで検証します。新旧を突き合わせて結果を比較するため、「動くはず」ではなく「同じ動作をすることを確認した」状態で移行できます。

現状把握から始める

Seasar2のバージョン、SAStrutsやS2JDBCの使用範囲、Struts 1系の併用有無、画面数、外部公開の範囲。この5点が整理できれば、対応方針と概算規模は見えてきます。

既存のソースコードから構造を自動解析し、移行対象の全体像と概算の移行規模をご提示することが可能です。サポート終了から10年が経過した環境を運用されている場合は、一度ご相談ください。