サーバ再起動不要のSMART deployとバリデーション：Java初心者が超俊敏にWebアプリを作る方法（3）（1/2 ページ）

Eclipseプラグイン「Dolteng」のScaffoldという自動生成機能やSeasar 2.4のHOT deploy機能を利用して、DBの参照・更新・削除ができるSAStrutsのWebアプリを作ります。Java初心者だけでなくStrutsに慣れた開発者も必見です

» 2008年12月18日 00時00分公開

[新田智啓，株式会社パワーエッジ]

　超俊敏にJavaのWebアプリケーションを作るための便利なツールを紹介する本連載も今回で3回目です。連載第1回の『1分でWebアプリを作れるEclipseプラグイン「Dolteng」』では、Webアプリケーション開発に非常に便利なEclipseプラグインである「Dolteng」の機能を使用して、「SAStruts」のプロジェクトを自動生成し、前回の「StrutsのXML地獄から開発者を解放するSAStruts」ではSAStrutsとStrutsでの設定の方法の基本的な違いを説明しました。

　今回はStruts設定ファイルの定義で残っていたバリデーション（入力チェック・検証）の比較の部分です。Strutsでのバリデーションの部分をSAStrutsでどのように定義できるか。そして、SAStrutsの全体の流れを追っていきます。Strutsのバリデーションについては以下が参考になると思います。

連載記事「Strutsを使うWebアプリケーション構築術」 via kwout

　なお今回も、第1回に作成した環境を使用しますので、まだ読んでいない方は、第1回を参照して環境を作成しておいてください。

コーディング作業を超俊敏にする「SMART deploy」

　いままでの連載で“謎”の言葉のままだった「SMART deploy」ですが、ここでSAStrutsのバリデーションよりも先に解説しておきたいと思います。SMART deployはDIコンテナである「Seasar」のバージョン2.4から実装されたデプロイ機能で、DI（依存性の注入）の技術が生かされています。デプロイ方法には「HOT」「COOL」「WARM」の3種類があります。

Seasar - DI Container with AOP - via kwout

　連載第2回までで、修正したソースコードをTomcatを再起動することなく適応できたのを覚えていますでしょうか。それは実は、SMART deployの機能の1つである「HOT deploy」で動作していたからなのです。なお、前回説明したとおり、SMART deployには「推奨しているパッケージ構成」がありますが、連載第1回のDoltengが自動生成したパッケージ構成は、すでに「推奨しているパッケージ構成」になっています。

アプリケーションサーバの再起動が要らない「HOT deploy」

　いままでのJavaのWebアプリケーション開発では、ソースコードを修正するたびにアプリケーションの再起動をしなければなりませんでした。しかし、HOT deployで動作させると、ソースコードの修正を俊敏にアプリケーションサーバに適応できるのです。処理概要は以下になります。

図1　HOT deployの処理概要（ユーザーからのリクエストのたびにこの処理が繰り返される）

　クラスローダについて詳しく知りたい読者は、以下の記事を参考にしてください。

＠IT：Java TIPS -- クラスローダの仕組みを知る via kwout

本番運用時には「COOL deploy」

　開発時には便利なHOT deployですが、若干パフォーマンスが悪くなります。本番運用のときはソースコードを変える必要はないので、要らない機能となってしまいます。そこでリリース時には、COOL deployで動作させます。図2を見ていただけると分かると思いますが、COOL deployを使うと、本来のパフォーマンスで動作させることができます。

図2　COOL deployの処理概要（HOT deployに比べ、非常にシンプルに動いている）

HOTとCOOLの中間はあたたか～い「WARM deploy」

　WARM deployは必要なとき必要なクラスを読み込むもので、HOT deployとCOOL deployの中間のような機能です。例えば、JUnitなどのテスティングフレームワークでテストをするときにはソースコードの変更はありません。しかし、単体テストではすべての機能を動作させるわけではないので、COOL Deployのときのようにプロジェクト全体のすべてのDI設定を行う必要はないはずです。

　すべての設定を行うと、当然それだけ起動が遅くなるので、必要ない部分を読み込みたくないときは、単体テストで必要な最小限の設定を読み込み、オブジェクトが生成できればいいわけです。そうしたときに使用するのがWARM deployです。

SMART deployを切り替えるには？

　SMART deployのモードを切り替えるには、「resource」フォルダの中にあるenv.txtを編集します。Doltengで生成されたenv.txtでは「ct」と書かれています。これを編集することによって以下のように動作させることができます。


入力する文字列	デプロイ方法
ct	HOT deploy
ut	WARM deploy
it	COOL deploy
env.txtなし	COOL deploy
表1　env.txtの設定

　itとenv.txtなしは、両方COOL deployで動作しますが、環境名としてSeasarでは別のものとして読み込まれます。それぞれを別のものとして使用するように推奨します。

注意！「複数人で1つのアプリケーションサーバを使うとき」

HOT deployでは、ActionやFormが複数リクエストを受けたときに正常に動作できないことがあります。複数人で1つのアプリケーションサーバを使うときにはHOT deployは使用しないようにしてください。また、本番環境に転送する場合にも気を付けてください。

　詳しい説明はSeasarの公式ページを参考にしてください。

StrutsとSAStrutsのバリデーションをコードで比較

　それでは、前回残っていた最後の設定ファイル、バリデーションについてStrutsとSAStrutsでの設定の仕方を比較していきます。今回見ていくクラスも前回同様DeptActionクラスとDeptFormクラスです。

　実は、連載第1回でDoltengで作成されたソースではバリデーションは設定されていませんでした。しかし、XMLの設定ファイルに書くことなく非常に簡単に設定できるので、ぜひやっていきましょう。

　まず、DeptFormのバリデーションを決めます。基本的に、データベースの形式に合わせて定義します。ここでは、以下の定義を加えます。

deptNo：必須、数字形式
deptName：最大20文字

　ここではサンプルなので上記2つのみ定義してみます。

Strutsでのバリデーション定義はXMLを使う

　例えば、Strutsの「validation.xml」で設定すると、以下のようになります。

<formset>

  <form name="deptForm">

    <!-- deptNo：必須チェック -->

    <field property="deptNo" depends="required">

    </field>

    <!-- deptNo：数字形式チェック -->

    <field property="deptNo" depends="integer">

    </field>



    <!-- deptName：最大文字数チェック -->

    <field property="deptName" depends="maxlength">

      <var>

        <var-name>maxlength</var-name>

        <var-value>20</var-value>

      </var>

    </field>

  </form>

</formset>