Struts1の基本構造と現代における運用上の重要ポイント
Apache Struts 1（以下Struts1）は、かつてJava Webアプリケーション開発のデファクトスタンダードとして君臨したMVCフレームワークです。現在では、セキュリティリスクやメンテナンス性の観点から新規採用されることは皆無ですが、レガシーシステムの保守・運用、あるいはマイグレーション（移行）プロジェクトに従事するエンジニアにとっては、避けて通れない技術スタックです。本稿では、Struts1のアーキテクチャの核心を再確認し、実務で遭遇しやすい落とし穴と、現代的な視点からの技術的知見を詳説します。
Struts1のアーキテクチャとリクエストフロー
Struts1は、J2EE（現在のJakarta EE）環境において、Model-View-Controller（MVC）デザインパターンを強制的に適用させることで、コードの秩序を維持する役割を担っていました。その中心にあるのは「ActionServlet」です。
1. クライアントからのリクエストがActionServlet（コントローラ）に到達する。
2. 設定ファイル（struts-config.xml）を参照し、リクエストパスに対応するActionFormとActionクラスを特定する。
3. ActionForm（モデル）にリクエストパラメータが自動的にバインドされる。
4. Actionクラスがビジネスロジックを呼び出し、処理結果をActionForwardとして返却する。
5. ActionForwardに基づき、JSP（ビュー）へフォワードされ、画面が表示される。
この一連の流れにおいて、最も重要なのは「struts-config.xml」による集中管理です。すべての遷移先やフォーム定義がXMLに集約されているため、大規模なシステムではこのXMLが肥大化し、可読性が著しく低下するという課題を抱えています。
サンプルコード：ActionとActionFormの実装
Struts1における最も標準的な実装例を示します。ActionFormはデータの受け渡しを担い、Actionは処理の制御を担います。
// 1. ActionFormの実装
public class LoginForm extends ActionForm {
private String userId;
private String password;
// getter/setterは必須
public void setUserId(String userId) { this.userId = userId; }
public String getUserId() { return userId; }
public void setPassword(String password) { this.password = password; }
public String getPassword() { return password; }
// 入力チェック用メソッド
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if (userId == null || userId.length() == 0) {
errors.add("userId", new ActionMessage("error.userId.required"));
}
return errors;
}
}
// 2. Actionの実装
public class LoginAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) {
LoginForm loginForm = (LoginForm) form;
// 認証ロジック（実際にはサービス層を呼び出す）
if ("admin".equals(loginForm.getUserId())) {
return mapping.findForward("success");
} else {
return mapping.findForward("failure");
}
}
}
つまずきポイントと実務上の注意点
Struts1の開発において、多くのエンジニアが直面する壁と、その背後にある技術的背景を解説します。
1. ActionFormのスコープ管理
ActionFormには「request」スコープと「session」スコープの2種類があります。デフォルトはsessionですが、不用意にsessionを利用すると、メモリリークや意図しないデータの引き継ぎが発生します。特に「画面を戻る」操作を行った際に、古いデータが残っていることでバグが生じるケースは非常に多いです。現代的な設計では、基本的にrequestスコープを使い、必要なデータのみをセッションに保持する設計が求められます。
2. validateメソッドの限界
ActionForm内のvalidateメソッドは、複雑なバリデーションには不向きです。例えば、「DBの値を参照してユニークチェックを行う」といった処理をここで行うと、ActionFormがビジネス層に依存してしまい、疎結合性が損なわれます。実務では、validateは形式チェックのみに留め、論理的なバリデーションはService層で処理するべきです。
3. セキュリティリスク（脆弱性）
Struts1は、過去に深刻な脆弱性（OGNLインジェクション等）が多数報告されています。特に「ActionFormのプロパティを動的に設定する機能」が悪用されるケースが多く、フレームワークのアップデートが停止している現在は、WAFによる防御や、コードレベルでの入力値検証の徹底が不可欠です。
実務アドバイス：レガシーシステムとの向き合い方
現在、Struts1を利用したシステムを運用している場合、以下の3点を意識してください。
第一に、「ビジネスロジックの分離」です。Struts1のActionクラス内にSQLを直接記述しているようなコードは、将来的な移行の最大の障壁となります。まずはロジックを別クラス（POJO）へ切り出すリファクタリングを優先しましょう。
第二に、「フレームワークの機能に依存しすぎないこと」。Struts1のタグライブラリ（html:textなど）は便利ですが、HTMLの柔軟な制御を阻害します。必要に応じてJavaScript/TypeScriptによるDOM操作を併用し、フレームワークの制約から脱却する準備をしておくべきです。
第三に、「移行戦略の早期策定」。Struts1はJava 8以降の環境で動かすこと自体が困難になるケースが増えています。Spring Bootなどのモダンなフレームワークへの移行を前提とした「Struts1からの脱却ロードマップ」を策定し、少しずつコードをモダンな形に書き換えていく「ストラングラー（Strangler）パターン」の適用を推奨します。
まとめ
Struts1は、Java Web開発の歴史を形作った偉大なフレームワークですが、現代のアプリケーション開発においては「負債」としての側面が強くなっています。しかし、そのアーキテクチャを深く理解することは、現代のSpring BootやJakarta EEの仕組みを理解する上で非常に有益です。
これからStruts1のプロジェクトに参画する方は、単に「動くものを作る」だけでなく、「なぜこの設計になっているのか」「どこがボトルネックになり得るのか」を常に自問自答してください。レガシーコードの改善は、単なる修正作業ではなく、エンジニアとしての設計能力を鍛える絶好の機会です。過去の技術を正しく理解し、安全に次世代のアーキテクチャへと移行させることこそが、プロフェッショナルなネットワークスペシャリスト、およびアプリケーションエンジニアの責務と言えるでしょう。
コメント