このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索の URL を出力します。
このスクリプトでは、 e-docs マニュアルに必要なバナーを出力します。
このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索のパラメータを出力します。
WebLogic Server アプリケーションの開発
エンタープライズ アプリケーションのデプロイメント記述子の要素
以下の節では、エンタープライズ アプリケーション デプロイメント記述子 application.xml
(J2EE 標準デプロイメント記述子) および weblogic-application.xml (WebLogic 固有のアプリケーション デプロイメント記述子) について説明します。
weblogic-application.xml ファイルは、WebLogic Server の拡張機能を使用していない場合は省略可能です。
weblogic-application.xml デプロイメント記述子の要素
以下の節では、「weblogic-application.xml スキーマ 」で定義されているさまざまな要素について説明します。weblogic-application.xml ファイルは、Sun Microsystems から提供された application.xml デプロイメント記述子を拡張した BEA WebLogic Server 固有のデプロイメント記述子です。このファイルで、アプリケーションで参照される共有 J2EE ライブラリや EJB キャッシングなどの機能をコンフィグレーションします。
ファイルは、アプリケーション アーカイブの META-INF
サブディレクトリにあります。以降の節では、ファイル内に表示される要素について説明します。
weblogic-application
weblogic-application
要素は、アプリケーションのデプロイメント記述子のルート要素です。
次の表では、weblogic-application
要素内で定義できる要素について説明します。
表 A-1 weblogic-application 要素
WebLogic アプリケーションの構成要素となる EJB モジュールに固有の情報が含まれる。現在、
ejb
要素では、アプリケーションのエンティティ Bean によって使用される任意の数のアプリケーション レベル キャッシュを指定できる。
ejb
要素内で定義できる要素の詳細については、「
ejb 」を参照。
対象アプリケーションに固有な XML 処理のパーサおよびエンティティ マッピングに関する情報を指定する。
xml
要素内で定義できる要素の詳細については、「
xml 」を参照。
ゼロまたは 1 つ以上、指定する。アプリケーション スコープの JDBC 接続プールを指定する。
jdbc-connection-pool
要素内で定義できる要素の詳細については、「
jdbc-connection-pool 」を参照。
security
要素内で定義できる要素の詳細については、「
security 」を参照。
ゼロまたは 1 つ以上、指定する。アプリケーションに関連のあるコンテナ インスタンスの動作に影響を与える、入力されないパラメータの指定に使用する。ここに示すパラメータが、現在サポートされている。また、weblogic-application.xml 内のこれらのパラメータでは、リクエストおよび応答に使用するデフォルトのエンコーディングを決定できる。
webapp.encoding.default - JDK でサポートされるエンコーディングを表す文字列に設定できる。設定されると、これによりサーブレットのリクエストと応答の処理に使用されるデフォルトのエンコーディングが定義される。この設定は、webapp.encoding.usevmdefault が true に設定されている場合には無視される。この値はまた、weblogic.xml の input-charset 要素による要求ストリームについてはオーバーライドされる。
webapp.encoding.usevmdefault - true にも false にも設定できる。true であれば、デフォルト エンコーディングの定義にはシステム プロパティ file.encoding が使用される。
このアプリケーションに含まれる Web アプリケーションの動作に影響を与える、次のパラメータが使用される。
webapp.getrealpath.accept_context_path - true にも false にも設定可能な、互換性スイッチ。true に設定すると、サーブレット API getRealPath に対する呼び出しにおいて、Web アプリケーションのコンテキスト パスの使用が許可される。
<param-name>webapp.encoding.default </param-name>
<param-value>UTF8</param-value>
application-param 要素内で定義できる要素の詳細については、「
application-param 」を参照。
classloader-structure 要素を使うと、このアプリケーションのクラスローダの構成を定義できる。宣言は、クラスローダの階層を表し、特定のモジュールを特定のノードに関連付ける、ツリー構造で表現される。モジュールのクラスは、この要素と関連付けられたクラスローダによってロードされる。
<module-uri>ejb1.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>ejb2.jar</module-uri>
classloader-structure 要素内で定義できる要素の詳細については、「
classloader-structure 」を参照。
ゼロまたは 1 つ以上、指定する。ユーザ定義のアプリケーション ライフサイクル リスナの登録に使用する。抽象基本クラス weblogic.application.ApplicationLifecycleListener を拡張するクラスです。
listener 要素内で定義できる要素の詳細については、「
listener 」を参照。
ゼロまたは 1 つ以上、指定する。ユーザ定義の起動クラスの登録に使用する。
startup 要素内で定義できる要素の詳細については、「
startup 」を参照。
注意 :
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server のリリース 9.0 以降では非推奨になりました。このクラスの代わりに、ライフサイクル リスナ イベントをアプリケーションで使用してください。詳細については、「アプリケーション ライフサイクル イベントのプログラミング 」を参照してください。
ゼロまたは 1 つ以上、指定する。ユーザ定義の停止クラスの登録に使用する。
shutdown 要素内で定義できる要素の詳細については、「
shutdown 」を参照。
注意 :
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server のリリース 9.0 以降では非推奨になりました。このクラスの代わりに、ライフサイクル リスナ イベントをアプリケーションで使用してください。詳細については、「アプリケーション ライフサイクル イベントのプログラミング 」を参照してください。
JMS または JDBC モジュールなど、単独の WebLogic アプリケーション モジュールを表す。
name
- モジュールの名前。
type
- モジュールの種類。有効な値は、JMS、JDBC、または Interception。
path
- モジュールを完全に記述する XML ファイルのパス。エンタープライズ アプリケーションのルートを基準にした相対パスで指定する。
次の例では、XML ファイル
jms/Workflows-jms.xml
で完全に記述された
Workflows
という JMS モジュールの指定方法を示す。
<module> <name>Workflows</name> <type>JMS</type> <path>jms/Workflows-jms.xml</path> </module>
library 要素内で定義できる要素の詳細については、「
library 」を参照。
ワーク マネージャ要求クラスの一種であるフェア シェア要求クラスを指定する。フェア シェア要求クラスは、要求の処理に必要なスレッド使用時間の平均比率を指定する。
<fair-share-request>
要素は、以下のいずれかの子要素を取ることができる。
name
- フェア シェア要求クラスの名前。
fair-share
- スレッド使用時間の平均比率を表す整数値。
ワーク マネージャ クラスの一種である応答時間要求クラスを指定する。応答時間要求クラスは、応答時間の目標値 (ミリ秒) を指定する。
<response-time-request>
要素は、以下のいずれかの子要素を取ることができる。
name
- 応答時間要求クラスの名前。
goal-ms
- 応答時間の目標値を示す整数。
ワーク マネージャ クラスの一種であるコンテキスト要求クラスを指定する。コンテキスト要求クラスは、現在のユーザまたは現在のユーザのグループなどのコンテキスト情報を基に、要求クラスを要求に割り当てる。
<context-request>
要素は、以下のいずれかの子要素を取ることができる。
name
- コンテキスト要求クラスの名前。
context-case
- コンテキストを記述する要素。
<context-case>
要素は、さらに以下のいずれかの子要素を取ることができる。
user-name
または group-name
- コンテキストが適用されるユーザまたはグループ。
request-class-name
- 要求クラスの名前。
ワーク マネージャ制約
max-threads-constraint
を指定する。ワーク マネージャ制約は、要求の実行用に割り当てられるスレッドの最大数と最小数、および WebLogic Server が要求を拒否するまでにキューまたは実行できる要求の合計数を定義する。
max-threads-constraint は、制約対象の作業セットからの要求を実行する同時スレッドの数を制限する。
<max-threads-constraint>
要素は、以下のいずれかの子要素を取ることができる。
name
- max-thread-constraint 制約の名前。
count
または pool-name
- 同時スレッドの最大数を示す整数、または最大数を決める接続プールの名前。
ワーク マネージャ制約
min-threads-constraint
を指定する。ワーク マネージャ制約は、要求の実行用に割り当てられるスレッドの最大数と最小数、および WebLogic Server が要求を拒否するまでにキューまたは実行できる要求の合計数を定義する。
min-threads-constraint は、デッドロックを回避するために、制約対象の要求に割り当てられるスレッドの数を保証する。
<min-threads-constraint>
要素は、以下のいずれかの子要素を取ることができる。
name
- min-thread-constraint 制約の名前。
count
- スレッドの最小数を示す整数。
ワーク マネージャ制約
capacity
を指定する。ワーク マネージャ制約は、要求の実行用に割り当てられるスレッドの最大数と最小数、および WebLogic Server が要求を拒否するまでにキューまたは実行できる要求の合計数を定義する。
capacity 制約を指定すると、サーバの容量制限に達した場合にのみ要求が拒否されるようになる。
<capacity>
要素は、以下のいずれかの子要素を取ることができる。
name
- capacity 制約の名前。
count
- スレッドの容量を示す整数。
アプリケーションに関連付けられたワーク マネージャを指定する。
work-manager 要素内で定義できる要素の詳細については、「
work-manager 」を参照。
<application-admin-mode-trigger>
アプリケーションを管理モードにするために必要なスタック スレッドの数を指定する。
max-stuck-thread-time
- スレッドがスタック内に残る最大時間 (秒)。
stuck-thread-count
- スタック スレッド ワーク マネージャをトリガするスタック スレッドの数。
サーブレット セッションのコンフィグレーション パラメータのリストを指定する。
<session-descriptor>
要素内で定義できる要素の詳細については、「
session-descriptor 」を参照。
ejb
次の表では、ejb
要素内で定義できる要素について説明します。
表 A-2 ejb 要素
ゼロまたは 1 つ以上、指定する。
entity-cache
要素は、実行時にエンティティ EJB インスタンスをキャッシュに入れるときに使用される名前付きアプリケーションレベル キャッシュの定義に使用される。個々のエンティティ Bean は、使用するアプリケーションレベル キャッシュのキャッシュ名を参照する。
weblogic-ejb-jar.xml
デプロイメント記述子では、エンティティ Bean は
entity-cache-ref
要素を使用してアプリケーションレベルのキャッシュを参照できる。
entity-cache-ref
内に、アプリケーションレベルのキャッシュにコンフィグレーションされている
entity-cache-name
要素を指定する必要がある。個々のキャッシュを参照するエンティティ Bean の数に制限はない。
アプリケーションレベルのキャッシュの場合、ExclusiveCache および MultiVersionCache という 2 つのデフォルト キャッシュが使用される。アプリケーションの設定で、これらのデフォルト キャッシュを明示的に定義して、非デフォルト値を指定する場合もある。キャッシング方式では、デフォルト キャッシュは変更できない。デフォルトで、キャッシュは最大サイズとして値 1000 を指定して max-beans-in-cache を使用する。
entity-cache
要素内で定義できる要素の詳細については、「
entity-cache 」を参照。
<start-mbds-with- application
アプリケーションを使用してメッセージ駆動型 Bean (MDBS) を起動できるように EJB コンテナをコンフィグレーションできる。true に設定されると、コンテナはアプリケーションの一部として MDBS を起動する。false に設定されると、コンテナは MDBS をキューに保持し、ポートでのリスンが開始されたときにサーバによって MDBS が起動される。
entity-cache
次の表では、entity-cache
要素内で定義できる要素について説明します。
表 A-3 entity-cache 要素
エンティティ Bean キャッシュのユニークな名前を指定する。この名前は、ear ファイル内でユニークなものとし、空の文字列は使用できない。
<entity-cache-name>ExclusiveCache</entity-cache-name>
この要素を指定した場合、
<max-cache-size>
を同時に指定することはできない。
キャッシュ内で許容されるエンティティ Bean の最大数を指定する。限度に達すると、Bean に対してパッシベーションが行われる場合がある。このメカニズムでは、個々のエンティティ Bean が必要とする実際のメモリ サイズは考慮されない。この要素は、1 以上の値に設定できる。
この要素を指定した場合、
<max-beans-in-cache>
を同時に指定することはできない。
エンティティ キャッシュのメモリ サイズの限度をバイト単位または MB 単位で指定するときに使用される。max-cache-size 要素を使用して最大サイズが指定されたキャッシュを Bean が使用する場合、Bean プロバイダで weblogic-ejb-jar.xml 記述子の Bean の平均サイズを見積もる必要がある。デフォルトでは、Bean の平均サイズは 100 バイトと想定されている。
ejb
要素内で定義できる要素の詳細については、「
max-cache-size 」を参照。
指定した時期にエンティティ キャッシュに表示可能な SQL クエリの最大数を指定する。
EJB コンテナが特定のアプリケーション レベル キャッシュでエンティティ Bean インスタンスを管理するときに使用する一般的な方式を指定する。キャッシュによって、メモリ内のエンティティ Bean インスタンスがバッファに移され、対応する主キー値に関連付けられる。
caching-strategy
要素の値は、以下のいずれかに限られる。
Exclusive - 主キー値ごとにメモリ内の Bean インスタンスを 1 つキャッシュに入れる。この固有のインスタンスは、通常、使用時に EJB コンテナの排他的ロックを使用してロックされ、同時にそのインスタンスを使用するトランザクションは 1 つだけになる。
MultiVersion - 各主キー値に対してメモリ内の複数の Bean インスタンスをキャッシュに入れる。各インスタンスを複数のトランザクションで同時に使用できる。
<caching-strategy>Exclusive</caching-strategy>
max-cache-size
次の表では、max-cache-size
要素内で定義できる要素について説明します。
表 A-4 max-cache-size 要素
<bytes>
または
<megabytes>
の指定が必須。
バイト単位で示されるエンティティ キャッシュのメモリ サイズ。
<bytes>
または
<megabytes>
の指定が必須。
MB 単位で示されるエンティティ キャッシュのメモリ サイズ。
xml
次の表では、xml 要素内で定義できる要素について説明します。
表 A-5 xml 要素
エンタープライズ アプリケーション用の特定の XML パーサまたはトランスフォーマの指定に使用される親要素。
parser-factory
要素内で定義できる要素の詳細については、「
parser-factory 」を参照。
ゼロまたは 1 つ以上、指定する。エンティティ マッピングを指定する。マッピングにより、特定のパブリック ID またはシステム ID の代替エンティティ URI が指定される。このエンティティ URI を検索するデフォルトの場所は、lib/xml/registry ディレクトリである。
entity-mapping
要素内で定義できる要素の詳細については、「
entity-mapping 」を参照。
parser-factory
次の表では、parser-factory 要素内で定義できる要素について説明します。
表 A-6 parser-factory 要素
対象アプリケーションだけで必要とされる XML 解析用の SAXParser ファクトリを設定できる。この要素によって、SAX スタイル解析に使用されるファクトリが指定される。
saxparser-factory
要素の設定をしないと、サーバ XML レジストリでコンフィグレーションされた SAXParser ファクトリ スタイルが使用される。
デフォルト値 : サーバ XML レジストリの設定
<document-builder-factory>
対象アプリケーションだけで必要とされる XML 解析用のドキュメント ビルダ ファクトリを設定できる。この要素によって、DOM スタイル解析に使用されるファクトリが決定される。
document-builder-factory
要素を設定しないと、サーバ XML レジストリでコンフィグレーションされた DOM スタイルが使用される。
デフォルト値 : サーバ XML レジストリの設定
対象アプリケーションだけで必要とされるスタイル シート処理用のトランスフォーマ エンジンを設定できる。この要素の値を指定しないと、サーバ XML レジストリでコンフィグレーションされた値が使用される。
デフォルト値 : サーバ XML レジストリの設定
entity-mapping
次の表では、entity-mapping 要素内で定義できる要素について説明します。
表 A-7 entity-mapping 要素
マップされたエンティティのパブリック ID を指定する。
マップされたエンティティのシステム ID を指定する。
マップされたエンティティのエンティティ URI を指定する。
cache-on-reference
cache-at-initialization
cache-never
デフォルト値は cache-on-reference。
jdbc-connection-pool
注意 :
jdbc-connection-pool
要素は非推奨です。エンタープライズ アプリケーションでデータ ソースを定義する場合は、アプリケーションとともに JDBC モジュールをパッケージ化できます。詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC アプリケーション モジュールのデプロイメントのコンフィグレーション 」を参照してください。
次の表では、jdbc-connection-pool 要素内で定義できる要素について説明します。
表 A-8 jdbc-connection-pool 要素
アプリケーション固有の JNDI ツリーにおける JNDI 名を指定する。
デフォルトの接続ファクトリ設定のオーバーライドを定義する接続パラメータを指定する。
user-name - 省略可能。user-name
要素は、JDBCDataSourceFactoryMBean の UserName のオーバーライドに使用される。
url - 省略可能。url
要素は、JDBCDataSourceFactoryMBean の URL のオーバーライドに使用される。
driver-class-name - 省略可能。driver-class-name
要素は、JDBCDataSourceFactoryMBean の DriverName のオーバーライドに使用される。
connection-params - ゼロまたは 1 つ以上、指定する。
parameter+ (param-value, param-name) - 1 つまたは複数、指定する。
connection-factory
要素内で定義できる要素の詳細については、「
connection-factory 」を参照。
pool-params
要素内で定義できる要素の詳細については、「
pool-params 」を参照。
WebLogic Server ドライバの動作を設定する。
driver-params 要素内で定義できる要素の詳細については、「
driver-params 」を参照。
connection-factory
次の表では、connection-factory 要素内で定義できる要素について説明します。
表 A-9 connection-factory 要素
config.xml ファイル内の JDBCDataSourceFactoryMBean の名前を指定する。
接続ファクトリの接続プロパティを指定する。
connection-properties
要素について定義できる要素は、次のとおり。
user-name - 省略可能。JDBCDataSourceFactoryMBean の UserName のオーバーライドに使用される。
password - 省略可能。JDBCDataSourceFactoryMBean の Password のオーバーライドに使用される。
url - 省略可能。JDBCDataSourceFactoryMBean の URL のオーバーライドに使用される。
driver-class-name - 省略可能。JDBCDataSourceFactoryMBean の DriverName のオーバーライドに使用される。
connection-params - ゼロまたは 1 つ以上、指定する。接続を確立する際にドライバに渡されるパラメータの設定に使用される。例:
<connection-params> <parameter> <description>Desc of param </description> <param-name>foo</param-name> <param-value>xyz</param-value> </parameter> </connection-params>
pool-params
次の表では、pool-params 要素内で定義できる要素について説明します。
表 A-10 pool-params 要素
プール内の接続数に影響を与えるパラメータを定義する。
initial-capacity - 省略可能。initial-capacity 要素は、プールの初期化時に作成される物理的なデータベース接続数を定義する。デフォルト値は 1。
max-capacity - 省略可能。max-capacity 要素は、プールに含める物理的なデータベースの最大接続数を定義する。ただし、JDBC ドライバによってこの値がさらに制限されることがある。デフォルト値は 1。
capacity-increment - 省略可能。capacity-increment 要素は、プール容量を拡張するときの増分を定義する。サービス リクエストのために利用可能となる物理的な接続が他にないとき、プールは必要なデータベースの物理的な接続数を作成し、プールに追加する。プール内の接続数は、max-capacity で設定された物理的な最大接続数を超えないように保持される。デフォルト値は 1。
shrinking-enabled - 省略可能。shrinking-enabled 要素は、使用されていない接続が検出された場合に、プールの容量を initial-capacity に戻すかどうかを指定する。
shrink-period-minutes - 省略可能。shrink-period-minutes 要素は、リクエストを満たすためにインクリメンタルに増やした接続プールを縮小するまで待機する時間 (分単位) を定義する。縮小を可能にするには、shrinking-enabled 要素を true に設定しておく必要がある。
shrink-frequency-seconds - 省略可能。
highest-num-waiters - 省略可能。
highest-num-unavailable - 省略可能。
XA DataSource のパラメータを定義する。
debug-level
- 省略可能。整数。debug-level 要素は、XA 処理のデバッグ レベルを定義する。デフォルト値は 0。
keep-conn-until-tx-complete-enabled
- 省略可能。ブール。keep-conn-until-tx-complete-enabled
要素を true に設定すると、トランザクションが完了するまで、XA 接続プールによって同一の XA 接続が分散トランザクションに関連付けられる。
end-only-once-enabled
- 省略可能。ブール。end-only-once-enabled 要素を true に設定すると、保留中の各 XAResource.start()
メソッドに対する XAResource.end() メソッドの呼び出しが一度に限られる。
recover-only-once-enabled
- 省略可能。ブール。recover-only-once-enabled 要素を true に設定すると、リソースに対する回復の呼び出しが一度に限られる。
tx-context-on-close-needed
- 省略可能。tx-context-on-close-needed
要素は、さまざまな JDBC オブジェクト (例 : 結果セット、ステートメント、接続など) を閉じるときに XA ドライバで分散トランザクション コンテキストが必要な場合、true に設定する。true に設定されると、JDBC オブジェクトを閉じるときに送出される SQL 例外のうち、トランザクション コンテキストでないものは無条件で受信される。
new-conn-for-commit-enabled
- 省略可能。ブール。new-conn-for-commit-enabled 要素を true に設定すると、特定の分散トランザクションのコミットおよびロールバック処理に専用の XA 接続が使用される。
prepared-statement-cache-size
- 非推奨 。省略可能。prepared-statement-cache-size 要素は、Prepared Statement のキャッシュ サイズの設定に使用する。このキャッシュ サイズは、特定の接続から作成される Prepared Statement の数を表し、後で使用できるようにキャッシュに格納される。Prepared Statement キャッシュ サイズを 0 に設定すると、キャッシュがオフになる。
注意 :
prepared-statement-cache-size
は非推奨。driver-params/prepared-statement
の cache-size
を使用のこと。詳細については、「driver-params 」を参照。
keep-logical-conn-open-on-release - 省略可能。ブール。keep-logical-conn-open-on-release 要素を true に設定すると、XA の物理的な接続が XA 接続プールに返されても JDBC の論理的な接続はオープンしたまま保持される。デフォルト値は false です。
local-transaction-supported - 省略可能。ブール。XA ドライバがグローバル トランザクションを使用しない SQL をサポートする場合には、local-transaction-supported を true に設定する。そうでない場合は、false に設定する。デフォルト値は false です。
resource-health-monitoring-enabled - 省略可能。resource-health-monitoring-enabled 要素は、対象接続プールに対して JTA リソース状態モニタ機能を有効にする場合には true に設定する。
xa-set-transaction-timeout - 省略可能。
使用場所 : xa-params
例:
<xa-set-transaction-timeout>
true
</xa-set-transaction-timeout>
xa-transaction-timeout - 省略可能。
xa-set-transaction-timeout の値を true に設定すると、トランザクション マネージャは XAResource.start を呼び出す前にリソースに対して setTransactionTimeout を呼び出す。トランザクション マネージャは、グローバル トランザクション タイムアウト値を渡す。この属性が 0 より大きい値に設定されていると、この値がグローバル トランザクション タイムアウトに代わって使用される。
デフォルト値 : 0
使用場所 : xa-params
例:
<xa-transaction-timeout>
30
</xa-transaction-timeout>
rollback-localtx-upon-connclose
- 省略可能。
rollback-localtx-upon-connclose
要素が true の場合、接続プールは接続をプールに戻す前に、その接続に対して rollback()
を呼び出す。
デフォルト値 :false
使用場所 : xa-params
例:
<rollback-localtx-upon-connclose>
true </rollback-localtx-upon-connclose>
各物理データベース接続を作成するまでにかかる遅延時間 (秒数) を設定する。データベース サーバによっては、複数の接続リクエストが短い間隔で繰り返されると処理できないものもある。このプロパティを使用すると、データベース サーバの処理が追いつくように、少しの間隔を空けることができる。この遅延は、データベースの物理的な接続が確立すると、プールの初期作成時とプールの有効期間中の両方で必ず行われる。
JDBC 接続リーク プロファイリングを有効化する。接続リークは、プールからの接続が close() メソッドの呼び出しで明示的にクローズされていない場合に発生する。接続リーク プロファイリングがアクティブの場合、プールは接続オブジェクトがプールから割り当てられ、クライアントに与えられたときにスタック トレースを格納する。接続リークが検出されたとき (接続オブジェクトのガベージ コレクションが行われたとき) に、このスタック トレースが報告される。
この要素はリソースを余計に使用し、接続プール処理を遅くする可能性があるので、プロダクション環境での使用は避けるほうがよい。
<connection-check-params>
プール内の接続がまだ有効であることを確認するチェックを行うかどうかを指定し、行う場合の時期と方法を定義する。
table-name - 省略可能。table-name 要素は、スキーマ内でクエリできるテーブルを定義する。
check-on-reserve-enabled
- 省略可能。check-on-reserve-enabled 要素が true に設定されると、ユーザに接続が渡される前に毎回接続がテストされる。
check-on-release-enabled - 省略可能。check-on-release-enabled 要素が true に設定されると、ユーザが接続をプールに返すときに毎回接続がテストされる。
refresh-minutes - 省略可能。refresh-minutes 要素が定義されると、定期的 (指定された分単位の時間) にトリガされる。トリガによって、プール内の各接続がまだ有効であることを確認するチェックが行われる。
check-on-create-enabled - 省略可能。true に設定すると、接続は作成時にテストされる。
connection-reserve-timeout-seconds - 省略可能。プールからの接続を予約する呼び出しのタイムアウト後の秒数。
connection-creation-retry-frequency-seconds - 省略可能。プールがデータベースへの接続を確立しようとする再試行の頻度。
inactive-connection-timeout-seconds - 省略可能。予約された接続が強制的にプールに返るように解放された後の非アクティブ期間の秒数。
<connection-check-params>
test-frequency-seconds - 省略可能。データベース接続テストの周期の秒数。test-frequency-seconds の期間が終わるたびに、未使用のデータベース接続は table-name を使ってテストされる。テストに合格しない接続は閉じられ、有効な物理データベース接続を再確立するために再び開かれる。table-name が設定されていない場合、テストは実行されない。
init-sql
- 省略可能。接続が作成されたときに自動的に実行される SQL クエリを指定する。
<remove-infected-connections-enabled>
アプリケーションが基底のベンダ接続オブジェクトを要求した場合に、接続がプールから削除されるかどうかを制御する。この属性を有効化すると、(接続がプールから削除され、新しい接続に置き換わるために) 基本的に接続のプールを無効化することになるので、パフォーマンスに影響が出る。
driver-params
次の表では、driver-params 要素内で定義できる要素について説明します。
表 A-11 driver-params 要素
driver-params 文を定義する。省略可能な要素 profiling-enabled が含まれる。
<statement>
<profiling-enabled>true
</profiling-enabled>
</statement>
JDBC の Prepared Statement キャッシュ プロファイリングの実行を有効化する。有効化されると、Prepared Statement のキャッシュ プロファイルが後で分析できるように外部ストレージに格納される。この機能はリソースを消費するので、プロダクション サーバでは無効にしておくのが望ましい。デフォルト値は false です。
profiling-enabled - 省略可能。
cache-profiling-threshold - 省略可能。cache-profiling-threshold 要素は、Prepared Statement キャッシュの状態がログに記録されるステートメント リクエストの数を定義する。この要素は出力量を最小にする。この機能はリソースを消費するので、プロダクション サーバでは無効にしておくのが望ましい。
cache-size - 省略可能。cache-size 要素は、Prepared Statement キャッシュのサイズを返す。このキャッシュ サイズは、特定の接続から作成される Prepared Statement の数を表し、後で使用できるようにキャッシュに格納される。
parameter-logging-enabled - 省略可能。SQL 応答プロファイリング時、Prepared Statement パラメータの値を格納できる。parameter-logging-enabled 要素を使用すると、ステートメント パラメータを格納できるようになる。この機能はリソースを消費するので、プロダクション サーバでは無効にしておくのが望ましい。
max-parameter-length - 省略可能。SQL 応答プロファイリング時、Prepared Statement パラメータの値を格納できる。max-parameter-length 要素は、JDBC SQL 応答プロファイリングのパラメータとして渡される文字列の最大の長さを定義する。この機能は多くのリソースを使用するため、パラメータのデータ長を制限して、出力量を減らすようにする必要がある。
cache-type - 省略可能。
各 ResultSet について、クライアントと WebLogic Server の間での行のプリフェッチを有効にするかどうかを指定する。
外部クライアントが JDBC を使用して WebLogic Server 経由でデータベースにアクセスするとき、行のプリフェッチを行うと 1 回のサーバ アクセスでサーバからクライアントに複数の行を取り出すことになるので、パフォーマンスが向上する。クライアントと WebLogic Server が同一の JVM 内にある場合は、
WebLogic Server がこの設定を無視され、行のプリフェッチは使用されない。
クライアント用にプリフェッチする結果セットの行数を指定する。
最適値はクエリの詳細によって異なる。一般に、この数を増やすと、特定の値に達するまでパフォーマンスが向上する。その値に達すると、それ以上数を増やしてもパフォーマンスはそれほど向上しない。
注意 :
通常、100 行に達した後では、パフォーマンスの向上が見られなくなる。ほとんどの状況では、デフォルト値で問題ない。
この要素の有効な値は 2 ~ 65536 で、デフォルト値は 48。
必要に応じて WebLogic Server からクライアントに取得されるストリーム データ型のデータ チャンク サイズを指定する。
security
次の表では、security 要素内で定義できる要素について説明します。
表 A-12 security 要素
アプリケーションが使用するセキュリティ レルムの名前を指定する。指定されていなければ、システムのデフォルト レルムが使用される。
<security-role-assignment>
アプリケーション ワイドなセキュリティ ロールと、1 つまたは複数の WebLogic Server プリンシパルとのマッピングを宣言する。
<security-role-assignment> <role-name> PayrollAdmin </role-name> <principal-name> Tanya </principal-name> <principal-name> Fred </principal-name> <principal-name> system </principal-name> </security-role-assignment>
application-param
次の表では、application-param 要素内で定義できる要素について説明します。
表 A-13 application-param 要素
classloader-structure
次の表では、classloader-structure 要素内で定義できる要素について説明します。
表 A-14 classloader-structure 要素
module-ref 要素内で定義できる要素は次のとおり。
module-uri - ゼロまたは 1 つ以上、指定する。module-ref 要素内で定義される。
アプリケーションのクラスローダ構造の任意のネスティングを有効にする。ただし、このバージョンの WebLogic Server では、指定可能な階層は 3 レベルまで。
listener
次の表では、listener 要素内で定義できる要素について説明します。
表 A-15 listener 要素
ApplicationLifecycleListener のユーザによる実装の名前。
実装が格納されている EAR 内の JAR ファイル。listener-uri を指定していない場合は、アプリケーションからクラスが見えるものと仮定する。
startup
次の表では、startup
要素内で定義できる要素について説明します。
警告 :
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server のリリース 9.0 以降では非推奨になりました。このクラスの代わりに、ライフサイクル リスナ イベントをアプリケーションで使用してください。詳細については、「アプリケーション ライフサイクル イベントのプログラミング 」を参照してください。
表 A-16 startup 要素
アプリケーションのデプロイ中に実行するクラスの名前を定義する。
startup-class が格納されている EAR 内の JAR ファイルを定義する。startup-uri が定義されていない場合は、アプリケーションからこのクラスが見えるものと見なす。
shutdown
次の表では、shutdown 要素内で定義できる要素について説明します。
警告 :
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server のリリース 9.0 以降では非推奨になりました。このクラスの代わりに、ライフサイクル リスナ イベントをアプリケーションで使用してください。詳細については、「アプリケーション ライフサイクル イベントのプログラミング 」を参照してください。
表 A-17 shutdown 要素
アプリケーションのアンデプロイ時に実行するクラスの名前を定義する。
shutdown-class が格納されている EAR 内の JAR ファイルを定義する。shutdown-uri を指定していない場合は、アプリケーションからクラスが見えるものと仮定する。
work-manager
次の表では、work-manager 要素内で定義できる要素について説明します。
ワーク マネージャの例および詳細については、「ワーク マネージャを使用したスケジューリング済み作業の最適化 」を参照してください。
表 A-18 work-manager 要素
<response-time-request-class>
<work-manager>
のこの子要素の詳細については、「
weblogic-application
」の
<response-time-request>
要素の説明を参照。
この要素を指定した場合、
<fair-share-request-class>
、
<context-request-class>
、または
<request-class-name>
を同時に指定することはできない。
<fair-share-request-class>
<work-manager>
のこの子要素の詳細については、「
weblogic-application
」の
<fair-share-request>
要素の説明を参照。
この要素を指定した場合、
<response-time-request-class>
、
<context-request-class>
、または
<request-class-name>
を同時に指定することはできない。
<work-manager>
のこの子要素の詳細については、「
weblogic-application
」の
<context-request>
要素の説明を参照。
この要素を指定した場合、
<fair-share-request-class>
、
<response-time-request-class>
、または
<request-class-name>
を同時に指定することはできない。
この要素を指定した場合、
<fair-share-request-class>
、
<context-request-class>
、または
<response-time-request-class>
を同時に指定することはできない。
<work-manager>
のこの子要素の詳細については、「
weblogic-application
」の
<min-threads-constraint>
要素の説明を参照。
この要素を指定した場合、
<min-threads-constraint-name>
を同時に指定することはできない。
<min-threads-constraint-name>
min-thread-constraint 制約の名前。
この要素を指定した場合、
<min-threads-constraint>
を同時に指定することはできない。
<work-manager>
のこの子要素の詳細については、「
weblogic-application
」の
<max-threads-constraint>
要素の説明を参照。
この要素を指定した場合、
<max-threads-constaint-name>
を同時に指定することはできない。
<max-threads-constraint-name>
max-thread-constraint 制約の名前。
この要素を指定した場合、
<max-threads-constaint>
を同時に指定することはできない。
<work-manager>
のこの子要素の詳細については、「
weblogic-application
」の
<capacity>
要素の説明を参照。
この要素を指定した場合、
<capacity-name>
を同時に指定することはできない。
この要素を指定した場合、
<capacity>
を同時に指定することはできない。
<work-manager-shutdown-trigger>
スタック スレッドに応答してワーク マネージャを停止できるスタック スレッド ワーク マネージャ コンポーネントの指定に使用する。
max-stuck-thread-time
- スレッドがスタック内に残る最大時間 (秒)。
stuck-thread-count
- スタック スレッド ワーク マネージャをトリガするスタック スレッドの数。
この要素を指定した場合、
<ignore-stuck-threads>
を同時に指定することはできない。
スレッドがスタックされた場合でも、ワーク マネージャがスタック スレッドを無視して停止しないかどうかを指定する。
この要素を指定した場合は、
<work-manager-shutdown-trigger>
を同時に指定することはできない。
session-descriptor
次の表では、session-descriptor 要素内で定義できる要素について説明します。
表 A-19 session-descriptor 要素
セッションがタイムアウトするまでの秒数を指定する。
<invalidation-interval-secs>
HTTP セッションのデバッグを有効にするかどうかを指定する。
HTTP リクエスト間のセッション トラッキングを有効にするかどうかを指定する。
JDBC とファイル永続化セッションのキャッシュ サイズを指定する。
メモリ/レプリケートされたセッションの最大セッション数を指定する。
Web アプリケーション コンテナが応答にクッキーを設定するかどうかを指定する。
セッション トラッキングを実行するクッキーの名前を指定する。
セッション トラッキング クッキーのパスを指定する。
セッション トラッキング クッキーのドメインを指定する。
セッション トラッキング クッキーのコメントを指定する。
セッション トラッキング クッキーが安全であることを示すかどうかを指定する。
セッション トラッキング クッキーの最大存続期間を指定する。
memory
- デフォルト値。
replicated
- クラスタ化が必要。
replicated_if_clustered
- クラスタ化されていない場合は memory
がデフォルト。
file
jdbc
cookie
<persistent-store-cookie-name>
cookie
ベースのセッションの永続性を使用する場合に、属性名と値を保持するクッキーの名前を指定する。
file
ベースのセッションの永続性を使用する場合に、ディレクトリの名前を指定する。ディレクトリは、Web アプリケーション用に定義された一時ディレクトリを基準にする。
jdbc
ベースのセッションの永続性を使用する場合に、JDBC 接続プールの名前を指定する。
jdbc
ベースのセッションの永続性を使用する場合に、データベース テーブルの名前を指定する。
デフォルト値は
wl_servlet_sessions
。
<jdbc-column-name-max-inactive-interval>
jdbc
ベースのセッションの永続性を使用する場合に、
wl_max_inactive_interval
列の代替名を指定する。長い列名をサポートしていない一部のデータベースでは必須。
<jdbc-connection-timeout-secs>
URL の書き換えが有効化されているかどうかを指定する。
<http-proxy-caching-of-cookies>
WebLogic Server が以下の HTTP ヘッダを応答に追加するかどうかを指定する。
Cache-control: no-cache=set-cookie
このヘッダは、プロキシ キャッシュがクッキーをキャッシュしないように指定する。
デフォルト値は
true
で、ヘッダは追加されない。ヘッダを応答に追加する場合は、この要素を
false
に設定する。
<encode-session-id-in-query-params>
WebLogic Server がパス パラメータのセッション ID をエンコードするかどうかを指定する。
<monitoring-attribute-name>
複数のセッションの実行時情報をタグ付けする場合に使用する。たとえば、ユニークであることが保証される
username
属性がある場合は、この要素を
username
に設定する。
複数の Web アプリケーション間で HTTP セッションを共有するかどうかを指定する。
library
次の表では、library 要素内で定義できる要素について説明します。
追加情報および例については、「共有 J2EE ライブラリおよびオプション パッケージの作成 」を参照。
表 A-20 library 要素
参照される共有 J2EE ライブラリの名前を指定する。
指定した仕様バージョンおよび実装バージョンと参照したライブラリの仕様バージョンおよび実装バージョンが完全一致する必要があるどうかを指定する。
参照される Web アプリケーションの共有 J2EE ライブラリのコンテキスト ルートを指定する。
weblogic-application.xml スキーマ
weblogic-application.xml
デプロイメント記述子ファイルの XML スキーマについては、「http://www.bea.com/ns/weblogic/90/weblogic-application.xsd 」 を参照してください。
application.xml スキーマ
application.xml
デプロイメント記述子の要素の詳細については、「http://java.sun.com/xml/ns/j2ee/application_1_4.xsd 」の J2EE 1.4 スキーマを参照してください。