特集
2004/04/23 17:45 更新


特集：第3回　Strutsをチーム開発に生かす「XDoclet」の活用 (2/8)


開発の現場では−その1：Struts設定ファイル容量が肥大化する

　よほど小規模なアプリケーションでない限り、Struts設定ファイルのサイズが数百行におよび、もはや人間が直接編集するには無理がある状況になってしまうのは、よくある話だ。そのため、Struts設定ファイルを直接編集せずにウィザードやGUIで編集するツールや統合開発環境プラグインなどが考案されている。しかし、これらのツール類はどれも一長一短なのが現実だ。Struts設定ファイルを直接編集しない、という目的は達せられるものの、ツール自身に機能が足りない、操作や設定の融通が利かない、動作に癖や制限がある……、などの問題が新たにつきまとうのを避けられない。

開発の現場では−その2：同一ファイルを複数人でメンテナンス

　また、システムの開発チームの人数が増えてくると同一ファイルを複数人数で編集することの問題点が見えてくる。この問題に対しては、Strutsではモジュール分割機能という答えを出している。モジュールの分割を行うとStruts設定ファイルを複数に分割して、同一アプリケーションをあたかも別アプリケーションのように作成することができる。

　しかし、この機能を使った場合はモジュール間の機能の呼び出しや遷移の際に特殊な記述や設定が必要になったり、独自のAPIを使う必要が出てきてしまい、あまり使い勝手のよい機能とはいえないのが現実だ。また、Strutsはモジュールの分割のほかにも、単純に複数の設定ファイルに分割して内容を記述できる機能も持っている。Struts設定ファイルをデプロイするパスと、ファイル名はweb.xmlのActionServletの初期化パラメータに記述するが、ここにカンマ区切りでパスを書き並べればよい。

リスト1■web.xmlに複数のStruts設定ファイルを登録する例
〜前略〜

<!-- Standard Action Servlet Configuration (with debugging) -->
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml, /WEB-INF/struts-config2.xml, …… </param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>

〜以下略〜

　分割する方法は幾つか存在するが、いくら分割ができても実際にはそれほどメンテナンス性の向上へと結びつかないものだ。プログラマ各人の担当単位で分割するのはあまりにも非現実的であり、結局複数人数で同一ファイルをメンテナンスすることには変わりがない。VSSやCVSを使ってファイルのバージョン管理、履歴管理を行っても、同時平行作業によって行われた変更をマージするのは人間の目と手で行うしかないのだ。

XDocletを使ったStrutsアプリケーション開発の流れ

　XDocletを使ったStrutsアプリケーション開発の流れは、次のようになる。

1. Struts設定ファイルを直接編集しない

　Struts設定ファイルはソースコードをビルドするたびに自動生成される。

2. Javadocコメント部分にXDoclet独自のタグを記述

　Struts設定ファイルに記述するような情報は、各AcitonクラスやActionFormクラスのJavadocコメント部分の記述するXDoclet独自タグで記述する。共通部分（コントローラやプラグインの設定など）は、別ファイルとして作成し、ビルドの際にマージすることが可能。

3. Apache Antでビルドする

　XDocletはAntタスクとして提供されているので、Antの使用は必須だ。基本的にはコマンドラインよりの操作となるが、EclipseなどのAntを使えるツールからの利用も可。

この記事で使用するソフトウェアとバージョン

　そのほかにも、ServletコンテナとしてApache Tomcat 4.1.30を使用する。このため、使用するAntビルドファイル（build.xml）も、Tomcat環境を前提として作成しているものだ。


Column1■TomcatのsetCharacterEncoding 問題

Servlet API2.3/2.4 仕様では、setCharacterEncodingメソッドはリクエストのボディに対して適用されるとあるが、リクエストヘッダに対しては明確な仕様が存在しない。そこで、これを厳密に解釈したTomcat実装チームはTomcat4.1.29/5.0.16/5.0.18 で、リクエストパラメータに対してsetCharacterEncodingメソッドによる文字エンコーディング指定が適用されなくなるように修正した。これは、W3CがUTF8の普及を期待したことにも関連する。つまり、POST送信時にはsetCharacterEncodingメソッドによるリクエストパラメータの文字エンコーディング名の指定が有効になり、GET送信時には無効になる動作を意味するのだ。

しかし、以前のバージョンとの互換性やボディとパラメータのエンコーディングの統一性の問題（GETとPOSTでパラメータの文字エンコーディングが異なることは現実にはほとんど無い）から、世界各地で反対の声が起こり、今後Servlet API仕様そのものが見直される可能性がある。

これにより、GET送信時にsetCharacterEncodingメソッドが動作しない場合は、下記のように実装する必要性があるのだ。

リストc1■GETの場合の実装例
// リクエストパラメータ"paramName"の値を取得
String value = request.getParameter("paramName");
// 取得したパラメータ値を一旦バイト配列に変換し、
// 文字エンコーディング名を指定してStringに再構築
value = new String(value.getBytes("ISO-8859-1"), "Windows-31J");

TomcatはServlet/JSPコンテナのリファレンス実装という位置づけなため、他のアプリケーションサーバもTomcatに準じた実装に変更される可能性があるため、注意が必要だ。

前のページ | 1 2 3 4 5 6 7 8 | 次のページ

[阿島哲夫，ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.