|
||||||||||
| 前のパッケージ 次のパッケージ | フレームあり フレームなし | |||||||||
参照:
説明
| クラスの概要 | |
| ArrayStack | Vector ではなく、 ArrayList ベースによる
java.util.Stack API の実装です。 |
| BeanUtils | 推奨されていません。 Struts 1.0 final以降のいずれかの時点で、Jakarta Commons Beanutils パッケージ中の同等なクラスに置き換えられます。 |
| ConvertUtils | 推奨されていません。 Struts 1.0 final以降のいずれかの時点で、Jakarta Commons Beanutils パッケージ中の同等なクラスに置き換えられます。 |
| ErrorMessages | 推奨されていません。 org.apache.struts.action.ActionErrors を使用してください |
| FastArrayList | 推奨されていません。 Struts 1.0 の最終版では、Jakarta Commons Collections パッケージ内の同等のクラスによって置き換えられます。 |
| FastHashMap | 推奨されていません。 Struts 1.0 final以降のいずれかの時点で、 Jakarta Commons Collections パッケージ中の同等なクラスに置き換えられます。 |
| FastTreeMap | 推奨されていません。 Struts 1.0 final以降のいずれかの時点で、 Jakarta Commons Collections パッケージ中の同等なクラスに置き換えられます。 |
| GenericConnection | 汎用的な Connection のラッパー実装です。 |
| GenericDataSource | DataSourceインタフェースの汎用的な実装です。
|
| IteratorAdapter | Enumeration を Iterator クラスへ変換するユーティリティメソッドです。 |
| MessageResources | 明確に定義されていないリソースのロケーションからLocale毎のメッセージを
取得し、MessageFormatクラスを使用して
国際化されたメッセージに対してパラメータ置換を行い
出力するためのAPIを記述した汎用的な目的をもつ抽象クラスです。
|
| MessageResourcesFactory | MessageResourcesインスタンスのファクトリーです。
|
| PropertyMessageResources | java.util.PropertyResourceBundle の規則に従った名称のプロパティリソースから
メッセージキーと一致する文字列を読み込む MessageResources の具象サブクラスです。
|
| PropertyMessageResourcesFactory | PropertyMessageResources インスタンスのファクトリです。
|
| PropertyUtils | 推奨されていません。 Struts 1.0 final以降のいずれかの時点で、Jakarta Commons Beanutils * パッケージ中の同等なクラスに置き換えられます。 |
| RequestUtils | Struts コントローラフレームワークにおけるサーブレットリクエストの処理に関する 汎用ユーティリティメソッド群です。 |
| ResponseUtils | Struts コントローラフレームワークにおけるサーブレットレスポンスの生成に関する 汎用ユーティリティメソッド群です。 |
| ServletContextWriter | javax.servlet.ServletContext のロギング機能を使用して
その結果を出力する、PrintWriter の実装です。
|
Utilitiesパッケージは、Webアプリケーションを構築する上でよく直面する問題を解決するために、
様々なファミリのクラス群を提供します。
StrutsのUtilitiesパッケージは、Webアプリケーションを構築する上でよく直面する問題を解決するために、 様々なファミリのクラス群を提供します。このパッケージで提供される殆どのクラスは、 コントローラサーブレットのフレームワークや、カスタムタグライブラリに依存しないため、 一般的なJavaアプリケーションプログラミングにも適しています。 以下のようなファミリが含まれています：
java.util.Localeオブジェクトと、
メッセージキーとの組に基いた、国際化されたメッセージへのアクセスを提供するクラスのファミリです。FIXME
FIXME この機能のいくつかの部分はTaglibsに移されるべきです。
BeanUtils と PropertyUtils はIteratorTag, WriteTag
も含めて、strutsの全てを通して使用されます。これらのユーティリティの多くは、
Java beans
を操作するためにJavaのリフレクションに依存し、またこれを利用しています。
妥当な Java bean が必須です！
簡単なProductBeanクラスを例に取ると、以下ではこれらのルールに従っています：
public class ProductBean() {
private String value;
public String getValue() (return this.value}
public void setValue(String value) (this.value = value}
}
これらの慣例を守ることで、不必要なエラーを避けることができ、時間を節約することができるでしょう。
これによって、以下のようなJSPページを作ることができます:
<logic:iterate id="product" name="receivedForm" property="receivedList">
<bean:write name="product" property="description" />
<bean:write name="product" property="value" />
</logic:iterate>
ここで、receiveFormは以下のように定義されるActionFormです
public class ReceivedForm extends ActionForm {
private ProductList productList;
public void setReceivedList(Enumeration enum) {
productList = new ProductList(enum,Limits.ARRAY_SIZE_MIN);
}
/**
* java.bean reflection がreceivedListのゲッターメソッドとしてgetReceivedList
* を認識できるように、これを定義します。
*/
public void setReceivedList(ProductList productlist) {
}
/**
* ProductBeansのリストを返します。
*/
public ProductList getReceivedList() {
return productList;
};
} //ReceiveForm
Java 2 Standard Edition (J2SE)のバージョン1.2では、Javaプログラミングにおいて広く有用である、
強力なcollectionクラスのセットが導入されました。これらは
java.util.Collection、java.util.List、java.util.Map、
そしてjava.util.Setといった基本インタフェースに基づいています。
JDK 1.1で利用できるcollectionクラス(主にjava.util.Hashtableとjava.util.Vector)
に比べて、新しいクラス群はより豊富な機能と同様にパフォーマンスを改善するための機会を提供しています。
パフォーマンス改善の可能性は、新しいクラス群へのアクセスに使われるメソッドにおいて、
HashtableとVectorにおけるメソッドのようにsynchronizedされていない事実から来ています。これは単一スレッドのアプリケーションにおいてメソッド呼び出しがずっと速く実行されることを意味します。
何故なら、(単一スレッドのアプリケーションでは)同期化は必要ないからです。
しかしマルチスレッド環境下では、別スレッドがcollectionを書き換えしているときのメソッド呼び出しの同期化の保証が開発者の手に委ねられています。
(webアプリケーションのような)マルチスレッドのサーバ環境においては、
アプリケーションの起動時にデータ構造が初期化され、
主に読み取り専用でアクセスされるケースが多くあります。
この一例がStrutsのコントローラアプリケーションで、起動時に(struts-config.xmlファイル
内の<action>要素に対応した)ActionMappingのインスタンスのcollectionを初期化します。
しかしながら、アプリケーションが動作中に利用可能なマッピングを動的に変更することは不正ではありません。
よって、安全のために、通常はこのようなcollectionへのアクセスを同期化する必要があるでしょう。
たとえこれらのアクセスの99%が読み取り専用で、同期化を必要としなくても。
これらのシナリオを扱うために、Strutsのutility packageは、 アクセスの大半が読み取り専用であるようなマルチスレッド環境下で、 毎回の動作を同期化することなく、それでもcollectionの実行時の書き換えの可能性から守られて動作するように設計された特別なcollectionのシリーズを含んでいます。
各collectionクラスは、２つのモードのうちのどちらかのモードで動作します：
すなわち、fastもしくはslowです。
最初に生成されたとき、そのcollectionはslowモードで動作します。
これはcollectionの内容を最初に生成するときに適しています。
最初の生成が完了すると、setFast(true)の呼び出しによって、
大半のアクセスが読み取り専用であるときにパフォーマンスが最大となるように
fastモードに切り替えられます。
slowモードで動作中には、このcollectionにアクセスする全てのメソッドは、
それが読み取り専用であっても同期化されます。結果として、Hashtable
とVectorによって実行されるのと同じようにパフォーマンスに影響します。
このモードはcollectionの内容を初期化するときや、大量の更新を行う必要があるときに適しています。
一方fastモードを使用すると、メソッド呼び出しは以下のように動作します：
これから分かるように、変更の操作はfastモードにおいてとても高価なものですが、 しかしこのようにすることで、 大半を占める読み取り専用の操作を最速で実行することが可能になります。
もしcollectionがマルチスレッド環境からアクセスされないのであれば、 最大のパフォーマンスを得るためには、 代わりに標準のcollectionクラスのどれかを同期化しないで使用するべきです。
fast及びslowモードで動作可能な、以下のcollectionクラスが含まれています:
java.util.ArrayListと同等です。java.util.HashMapと同等です。java.util.TreeMapと同等です。webアプリケーションの多くでは、恒常的に保存される情報にアクセス、 またはそれらを更新するためにリレーショナルデータベースとのやりとりが必要になります。 典型的なクライアント−サーバアプリケーションでは、 各ユーザがプログラムの初期化時に各々の接続をオープンし、 そのアプリケーションが開いている間その接続を使用します。
アクティブなユーザの数がそれなりに限定されているような環境下ではこのアプローチはうまく動作しますが、 同時ユーザ数がとても多くなりうるwebアプリケーションには適用できません。 加えて、データベース接続のオープンには(それが頻繁に使われない場合でも)いくらかのオーバヘッドコストが伴い、 さらに殆どのwebアプリケーションのユーザは、 (ある特定の瞬間において)頻繁にデータベースにアクセスしているよりはむしろ、 以前に生成されたページの内容を読んで(或いは次の入力情報をタイプして)います。
このような状況を扱う為に、いくつかの基本的戦略が考えられます：
最初の戦略はシンプルであるという長所があります−単に必要となったときにデータベース接続をオープンし、 適切なデータアクセス及び更新を実行し、接続を閉じれば良いのです。 しかし、これには大きな欠点があります：殆どのデータベースにおいて、 数ミリ秒しか必要としないデータベーストランザクションを実行するためにも、 接続の確立にはとても時間がかかります(しばしば数秒を必要とします)。
２番目の戦略のように、各ユーザ毎に接続をオープンする方法は、 先に述べたクライアント−サーバアプリケーションでのアプローチに似ています。 (多くのイントラネットベースのアプリケーションのように) 同時接続ユーザ数が十分に処理できる数にコントロールできる場合は、 このアプローチは実際的です。 しかし、(多くの典型的なインターネット上の公開されたアプリケーションのように) ユーザ数がとても大きな数に急激に増えるような場合には、処理しきれなくなりますし、 さらに、少ない数の接続を共用する戦略よりも多くのオーバヘッドが要求されます。
接続プーリングは３番目の戦略の実装です。 これは、 「殆どのwebアプリケーションのユーザは最後にブラウザに送られたページとローカルでやりとりをしている」 という前提に基づいています。 ある特定の瞬間に実際にリクエストを送っているユーザの数は、 通常実際のアクティブなユーザ総数のうちのとても小さな割合でしかなく、 そしてリクエストが処理されている間だけがデータベース接続が必要な時間なのです。
Strutsはorg.apache.struts.util.GenericDataSourceと呼ばれる、
シンプルな接続プールのクラスを提供します。
これによって、特定のデータベースに、特定のJDBCドライバを使って(同じ接続パラメータを用いた)接続のセットを構成し、
(サーブレットコンテナ中で同時にアクティヴな様々なリクエストスレッドのように)
同時に動作するいくつかのスレッド間でこれらの接続を共用することができます。
GenericDataSourceクラスはJava Database Connectivity(version 2.0) Standard Extension API
のjavax.sql.DataSourceインタフェースを実装しており、
このクラスにアクセスするプログラムはクラス名を直接参照せずにこのインタフェースを参照すべきです。
そうすることによって、アプリケーションに少し変更を加えるだけで、或いは変更を加えずに、
更に進んだ接続プールの実装へ乗り換えることができます。
JDBC 2.0 Standard Extension APIについての更なる情報については、 仕様(及び関連するAPIクラス)をhttp://java.sun.com/products/jdbc からダウンロードできます。 このwebアドレスからは、利用可能なJDBCドライバについてやプログラミングチュートリアル等について、 他の多数の情報への入り口も見つけることができます。
以下の説明は接続プールのクラスをJavaアプリケーションからどのように設定し、 使用するかを示します。以下から分かるように、 Strutsのコントローラサーブレットは１つまたはそれ以上の接続プールを構成し、 接続プールのインスタンスをサーブレットコンテキストの属性値(JSPの用語でアプリケーションスコープのbeans) にすることによって、ActionクラスとJSPページから利用できるようにするための便利な機構を提供します。
GenericDataSourceのインスタンスを構成するためには、
先ず一つインスタンスを生成します：
GenericDataSource dataSource =
new GenericDataSource();
次に、このクラスによって提供されている、対応するJavaBeansプロパティのセッターメソッドを呼び出して、 適切なプロパティを設定する必要があります。 (利用可能なプロパティについての詳細についてはGenericDataSource クラスのJavadocを参照してください) Postgres databaseを使って接続プールオブジェクトを構成する例は以下のようになります：
dataSource.setAutoCommit(false);
dataSource.setDescription("My Database Connection Pool");
dataSource.setDriverClass("org.postgresql.Driver");
dataSource.setMaxCount(4);
dataSource.setMinCount(1);
dataSource.setPassword("mypassword");
dataSource.setUrl("jdbc:postgresql://localhost/mydatabase");
dataSource.setUser("myusername");
最後に、接続プールをopen()しなければなりません。
これはデータベースに(minCountに設定された値に基いて)最初の接続を確立します。
マルチスレッド下でプールから接続を使用していくに従って、
(maxCountに設定された値になるまで)必要に応じて追加の接続が生成されます。
try {
dataSource.open();
} catch (SQLException e) {
... 例外の処理 ...
}
接続プールを完全に利用し終わったら、 以下を実行することで現在オープンされている全てのデータベース接続を完全にクローズすることができます。
try {
dataSource.close();
} catch (SQLException e) {
... 例外の処理 ...
}
アプリケーションクラスからデータベースにアクセスするには、 接続が必要となる毎に、簡単な４段階の手順を踏まねばなりません：
この手順を実行するための一連のコードは以下のようになります。：
DataSource dataSource = ... dataSourceへの参照の取得 ...
Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
conn = dataSource.getConnection();
stmt = conn.prepareStatement("SELECT cust_id, name FROM customers" +
" WHERE (last_purchase_date >= ?)" +
" ORDER BY name");
stmt.setDate(1, lastPurchaseDate);
rs = stmt.executeQuery();
while ((row = rs.next()) != null) {
... このローの処理 ...
}
rs.close();
rs = null;
stmt.close();
stmt = null;
conn.commit();
conn.close();
conn = null;
} catch (SQLException e) {
if (rs != null) {
try {
rs.close();
} catch (SQLException f) {
;
}
rs = null;
}
if (stmt != null) {
try {
stmt.close();
} catch (SQLException f) {
;
}
stmt = null;
}
if (conn != null) {
try {
conn.rollback();
} catch (SQLException f) {
... 例外の処理 ...
}
}
... 例外の処理 ...
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException f) {
... 例外の処理 ...
}
conn = null;
}
}
今までJDBC接続を単独で利用していた開発者は、
Connectionのclose()を呼び出すという考え方に驚くでしょう。
通常、この呼び出しはConnectionの裏にあるデータベースへのリンクを切断し、
そのConnectionを以降の操作に関して利用不能にします。
しかし、接続プール環境下で使用された場合、getConnection()
の呼び出しによって取得された実際のConnectionは、
本当のJDBC Connectionインスタンスのカスタマイズされた「ラッパ」となります。
このラッパにおけるclose()の呼び出しは、単にこの接続をプールに返却するだけです。
アプリケーションがプールに接続を返却するのに失敗すると何が起こるでしょうか？ 想像できるように、この接続がサーバから見て「失われた」ことになり、２度と使われることはありません。 (接続プールそのものの寿命を通してデータベースに接続したままになっていても) もしこれが何度も繰り返されると、いつか利用可能な接続を使い切ってしまい、 アプリケーションの処理がストップしてしまうでしょう。
この問題を避けるために、
アプリケーションのロジックはその中でどのような問題が起こったとしても、
常に割り当てられた接続をプールに返却することを保証しなければなりません。
Java言語はこれを実現するために便利な機構を提供しています−
上記のコードのようにfinallyブロックを使用します。
接続が常に返却されることを保証するための方法はこれだけではありませんが、
とても便利な方法です。
もしアプリケーションがStrutsのコントローラサーブレット(org.apache.struts.action.ActionServlet)の基で動作しているならば、struts-config.xmlファイルに含まれる情報に基いて一つまたはそれ以上の接続プールを予め設定できる機能を利用することができます。単に、以下のようなセクションを含めれば良いのです。：
<data-sources>
<data-source>
<set-property property="autoCommit"
value="false"/>
<set-property property="description"
value="Example Data Source Configuration"/>
<set-property property="driverClass"
value="org.postgresql.Driver"/>
<set-property property="maxCount"
value="4"/>
<set-property property="minCount"
value="2"/>
<set-property property="password"
value="mypassword"/>
<set-property property="url"
value="jdbc:postgresql://localhost/mydatabase"/>
<set-property property="user"
value="myusername"/>
</data-source>
</data-sources>
初期化後、接続プールはkey属性に設定されたbean名で、
サーブレットコンテキストの属性として保存されます。
keyを設定しなかった場合には、デフォルトのkeyは文字列定数
Action.DATA_SOURCE_KEYの値となります。
こうして、Actionクラスの中から以下のように接続にアクセスし、
利用することができます(デフォルトデータソースの場合)：
DataSource dataSource = (DataSource)
servlet.getServletContext().getAttribute(Action.DATA_SOURCE_KEY);
conn = dataSource.getConnection();
... 前の例のように必要な機能を実行する ...
conn.close();
最近のアプリケーションでは、 サーバプラットフォームに設定されたデフォルトの言語以外の言語で利用したいユーザの為に、 複数の言語のサポートがしばしば要求されます。 加えて、多くの文章は、その言語における標準的な文章構造によってメッセージ中の位置が変化するような、 動的な内容によって構成される必要があります。
標準のJavaプラットフォームは、標準的な「キー」に基くメッセージ文字列の走査をサポートするように設計された
クラス(java.util.ResourceBundle) のファミリを含んでいます。
リソースバンドルクラスは自動的に、クラス(あるいはファイル)中のメッセージが属するLocaleを含んだ命名規則によって命名されたJavaクラス(あるいはプロパティファイル)にアクセスします。
しかし、この選択はサーバプラットフォームのデフォルトロケールにのみ基くもので、
国際化されたwebアプリケーションで必要とされるように、ユーザ毎に調整することはできません。
Strutsは、キーによってメッセージを走査する基本的なアプローチを拡張し、
キーに拠ってロケールを指定することもできるように拡張されたクラス
(org.apache.struts.util.MessageResources)のファミリを含んでいます。
これにより、ユーザに使用したいロケールを選ばせ、
その言語でのメッセージを走査させるようなアプリケーションを構築することができます。
- どんな言語が選ばれていようと、同じキーを用いて。
メッセージ走査における動的なロケールの選択のサポートに加えて、
MessageResourcesファミリのクラスは走査されたメッセージ中で"{0}"から"{3}"までのパラメータ置換子を置き換えるための、最大４つまでのパラメータ置換オブジェクトを指定することも可能にしています。
この置換操作はJava標準のjava.text.MessageFormatクラスを用いており、
これは他のたくさんの拡張フォーマッティング能力も同様に備えています。
国際化されたメッセージについてのさらなる情報は、 Java Development Kitに同梱された以下のリソースを参照してください：
<$JAVA_HOME/docs/guide/internat/index.html>で見つけることができます。
"Internationalization Overview"のセクションはロケール、ローカライズされたリソース、
メッセージフォーマッティング及びその他関連事項に関する有用な情報を含んでいます。java.text.MessageFormat
java.util.ResourceBundle
java.util.PropertyResourceBundle
java.util.Properties - 準備するpropertiesファイルの妥当な文法については、
load()メソッドの記述を参照してください。Strutsライブラリによって提供される標準のMessageResources実装はメッセージ文字列の初期化のためにJavaのpropertiesファイルをjava.util.PropertyResourceBundleクラスによってサポートされるのととてもよく似た方法で利用します。以降の手順はJavaアプリケーションにおいてこれらの機能を利用するために必要です。
最初に、メッセージでサポートしたい言語（またはロケール）毎にJavaプロパティファイルを用意します。 ファイル名は、上記の参照ドキュメントに述べられているプロパティリソースバンドルの命名規則に準拠しなければなりません。 各ファイル内では、同じメッセージを特定するのに必ず同じメッセージキーを使うようにしてください。
例えば、「Hello」という言葉の各言語バージョンを含む、フランス語、
スペイン語及び英語のプロパティファイルを用意したとしましょう。
フランス語用のファイルはMessages_fr.propertiesというファイル名となり、
hi=Bonjour
という内容を含みます。
それに対して、スペイン語用及び英語用のファイルはそれぞれ
Messages_es.propertiesとMessages_en.propertiesになります。
これらの中で、対応するメッセージの文字列定義はhi=Hola及びhi=Helloになるでしょう。
次にこれらのプロパティファイルを、クラスファイル自身と全く同様に、 アプリケーションのクラスパスの通った場所に配置します。 リソースをロードするために実際に用いられる名称は、（適切なパッケージ名が前に付いた）、 完全修飾されたJavaクラスファイル名のようになります。 よって、ファイルはパッケージ名にマッチするディレクトリ構造の中（展開されたディレクトリ、 又はJARファイルの中身、どちらか適切な方）に含まれることになります。 例えば、"foo"というディレクトリがクラスパスに含まれていて、上記プロパティファイルが "foo/com/mycompany/maypackage"にあったとしましょう。 （もし"foo.jar"のようなJARファイルが代わりに用いられていたとしたら、 ファイルはJARファイル中の"com/mycompany/mypackage"にあることになります）
三番目に、特定のパッケージ中にある、
特定の名前のプロパティファイルの集合に対応したMessageResourcesオブジェクトを初期化します。
これを実現するもっとも簡単な方法は、メインアプリケーションクラス中で、以下のように変数を初期化する方法です。
public static MessageResources messages =
MessageResources.getMessageResources("com.mycompany.mypackage.Messages");
ここで、名前の一部である"com.mycompany.mypackage"はプロパティファイルを配置したパッケージディレクトリに等しく、
"Messages"がこのMessageResourcesのインスタンスによってサポートされる、
特定のプロパティファイルのファミリのファイル名のプレフィックスであることに注意してください。
開発プロセスによって、アプリケーション全体のメッセージ文字列をただ一つのプロパティファイルのファミリに保持するのがいいのか、いくつかのファミリに保持するのがいいのか分かるでしょう
−Strutsでは、例えば、各Javaパッケージ毎にプロパティファイルのファミリがあります。
特定のロケールでメッセージ文字列にアクセスするには、以下のようなコードを実行します：
Locale locale = ... 使用するロケールの選択 ...
String message = messages.getMessage(locale, "hi");
この例では、変数messageの値は、キー"hi"に対応する選択されたロケールに対応したメッセージです。
置き換え可能なパラメータを伴うメッセージフォーマットの例として、 メッセージ文字列が以下のようになっているとします。 (英語バージョンのみを示します−他のファイルでは適切な変更がされるはずです)：
hi=Hello {0}
すると、以下のように取得されるメッセージをパーソナライズすることができます：
Locale locale = ... 使用されるロケールの選択 ...
String name = "Joe";
String message = messages.getMessage(locale, "hi", name);
どんな言語が用いられていても、マーカー"{0}"は指定された名前(Joe)で置き換えられます。
パラメータ置換メカニズムのさらなる利用については、java.text.MessageFormat
のJavaDoc APIドキュメントを参照してください。
上記の例では、メッセージ文字列の保持にプロパティファイルを用いる、
Strutsによって提供されるデフォルトのMessageResourcesの実装を用いました。
メッセージの取得のために、独自のメカニズムを生成することも可能です
(必要に応じてデータベースから読み込む等)。必要な手順は以下のようになります。
org.apache.struts.util.MessageResourcesのサブクラスを作ります。createResourcesが呼び出された時に独自のMessageResourcesクラスのインスタンスを生成する、独自のorg.apache.struts.util.MessageResourcesFactoryのサブクラスを作ります。
このメソッドの"config"引数は、必要に応じたどんな方法ででも、
メッセージのファミリを選択するために使えるということに注目してください−
標準のMessageResourcesFactoryで用いられている、
「完全修飾されたJavaクラス名」を使うアプローチを模倣する必要はありません。MessageResourcesFactoryクラスに、新しいファクトリのインスタンスを生成するときに用いる独自のMessageResourcesFactoryの実装を設定します。MessageResourcesのインスタンスの生成を依頼します。以下のようなコードがこのテクニックの実例となります：
MessageResourcesFactory.setFactoryClass("com.mycompany.mypkg.MyFactory");
MessageResourcesFactory factory = MessageResourcesFactory.createFactory();
MessageResources resources =
factory.createResources("configuration information");
独自のMessageResourcesのインスタンスを生成した後は、 メッセージ文字列（パラメータの置き換えがあってもなくても）にアクセスするのにそれを用いることができます。 前節で説明した、標準の実装と全く同じ要領です。
アプリケーションでStrutsのコントローラサーブレットを用いるならば、 アプリケーション独自のメッセージリソースのインスタンスをロードして、 サーブレットコンテキストの属性(JSPの用語ではアプリケーションスコープのBean)として利用できるようにStrutsを設定することもできます。 このメカニズムは、webアプリケーションの配備記述子に以下のサーブレット初期化パラメータを設定することによって制御することができます：
createResources()メソッドに渡される設定文字列です。
標準のメッセージリソースファクトリを用いる場合は、以前に説明したように、
これらのメッセージを含むプロパティリソースファイルの完全修飾された名称でなければなりません。MessageResourcesFactoryの完全修飾されたJavaクラス名。
デフォルトでは、Strutsによる標準実装(org.apache.struts.util.PropertyMessageResourcesFactory)が用いられます。Strutsは、文字列定数Action.LOCALE_KEYによって名づけられたキーでの、
ユーザのセッションにおけるjava.util.Locale属性の存在を前提とした、
様々なJSPカスタムタグを提供します。
いつでも独自のアプリケーションロジックによってこの値を設定することもできますし、
（もし設定されていなければ）リクエストに含まれているHTTPヘッダーAccept-Languageに基づいて、
自動的に設定されるようにStrutsに依頼することもできます。
Strutsにこのサービスを依頼するには２つの方法があります：
localeをtrueに設定します。<form:html ... locale="true" ... />タグを使用します。
|
||||||||||
| 前のパッケージ 次のパッケージ | フレームあり フレームなし | |||||||||