| Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
戻る |
次へ |
このマニュアルは、WebLogic Server 固有のデプロイメント記述子 weblogic.xml の要素に関する詳細なリファレンスです。お使いの Web アプリケーションに weblogic.xml デプロイメント記述子が含まれていない場合、WebLogic Server によってこのデプロイメント記述子の要素にデフォルトの値が自動的に選択されます。
以降の節では、weblogic.xml デプロイメント記述子のルート要素 <weblogic-web-app> の下に定義できる複合的なデプロイメント記述子要素について説明します。
WebLogic Server の weblogic.xml ファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
weblogic.xml のスキーマについては、http://xmlns.oracle.com/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd を参照してください。
description 要素は、Web アプリケーションの説明文です。
weblogic-version 要素は、当該 Web アプリケーション (ルート要素 <weblogic-web-app> に定義) のデプロイ先とする WebLogic Server のバージョンを示します。この要素は参照用で、現在 WebLogic Server では使用されていません。
security-role-assignment 要素は、Web アプリケーションのセキュリティ ロールと WebLogic Server の 1 つまたは複数のプリンシパルとのマッピングを宣言します。次に例を示します。
<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>
この要素を使用すると、次の例のように、特定のロールを外部定義されたロールとしてマークすることもできます。
<security-role-assignment> <role-name>roleadmin</role-name> <externally-defined/> </security-role-assignment>
|
注意 : <security-role-assignment> 要素には、<principal-name> または <externally-defined> のどちらかが定義されている必要があります。この両方を省略することはできません。 |
次の表では、security-role-assignment 要素内で定義できる要素について説明します。
表 B-1 security-role-assignment 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<role-name> |
必須 |
セキュリティ ロール名を指定する。 |
<principal-name> |
|
セキュリティ レルムで定義されるプリンシパルの名前を指定する。複数の |
<externally-defined> |
|
特定のセキュリティ ロールがセキュリティ レルムでグローバルに定義されていることを指定する。WebLogic Server では、このセキュリティ ロールをグローバル レルム内でルックアップするのではなくプリンシパル名として使用する。セキュリティ ロールと principal-name のマッピングが別の場所で定義されている場合、これは暗示的なプレースホルダとして使用される。 |
security-role-assignment 要素およびその下位要素を定義していない場合は、Web アプリケーション コンテナによってロール名がプリンシパル名として暗黙的にマップされ、ログに警告メッセージが出力されます。マッピングが定義されていないと、EJB コンテナはモジュールをデプロイしません。
以下に、ロール名が「role_xyz」の場合の使用例を示します。
weblogic.xml で「role_xyz」をユーザ「joe」にマップすると、role_xyz がローカル ロールになる。
role_xyz を外部定義されたロールとして指定すると、これがグローバルになる (レルム レベルで定義されたロールを参照する)。
security-role-assignment 要素を定義しないと、role_xyz がローカル ロールになる。この場合、Web アプリケーション コンテナによって暗黙的なマッピングが作成され、ログに警告メッセージが出力されます。
run-as-role-assignment 要素は、web.xml の run-as ロール名 (servlet 要素の下位要素) をシステムの有効なユーザ名にマップします。この値は、servlet-descriptor の run-as-principal-name 要素によって任意のサーブレットについてオーバーライドできます。ロール名の run-as-role-assignment がない場合は、Web アプリケーション コンテナにより security-role-assignment に定義されている最初の principal-name が使用されます。以下の例に、run-as-role-assignment 要素の使い方を示します。
<run-as-role-assignment> <role-name>RunAsRoleName</role-name> <run-as-principal-name>joe</run-as-principal-name> </run-as-role-assignment>
次の表では、run-as-role-assignment 要素内で定義できる要素について説明します。
resource-description 要素は、サーバ リソースの JNDI 名を、WebLogic Server の EJB リソースの参照にマップするために使用されます。
次の表では、resource-description 要素内で定義できる要素について説明します。
resource-env-description 要素は、ejb-jar.xml デプロイメント記述子で宣言された resource-env-ref を、それが表しているサーバ リソースの JNDI 名にマップします。
次の表では、resource-env-description 要素内で定義できる要素について説明します。
次の表では、ejb-reference-description 要素内で定義できる要素について説明します。
次の表では、service-reference-description 要素内で定義できる要素について説明します。
session-descriptor 要素には、サーブレット セッションのパラメータを定義します。
表 B-7 session-descriptor
| 要素名 | デフォルト値 | 値 |
|---|---|---|
timeout-secs |
3600 |
WebLogic Server でセッションをタイム アウトするまでに待機する時間を秒単位で指定する。デフォルト値は 3600 秒。 トラフィックの多いサイトでは、セッションのタイムアウトを調整すると、アプリケーションの動作を最適化できる。ブラウザ クライアントでいつでもセッションを終了できるようにする必要がある場合でも、ユーザがサイトを離れるか、ユーザのセッションがタイムアウトになれば、サーバに接続する必要はなくなる。 この属性は、 |
invalidation-interval-secs |
60 |
WebLogic Server が、タイムアウトの無効なセッションに対してハウスクリーニング チェックを実行してから古いセッションを削除してメモリを解放するまでの待ち時間を秒単位で設定する。この要素を使用すると、トラフィックの多いサイトで WebLogic Server の動作を最適化できる。 デフォルト値は 60 秒。 |
sharing-enabled |
false |
アプリケーション レベルでこの値を Web アプリケーション レベルで有効になっている場合、この要素は無視される。 |
|
debug-enabled |
false |
HTTP セッションのデバッグ機能を有効にする。 デフォルト値は |
id-length |
52 |
セッション ID のサイズを設定する。 最小値は 8 バイト、最大値は WAP アプリケーションを作成する場合、WAP プロトコルはクッキーをサポートしていないため、URL を書き換える必要がある。また、一部の WAP デバイスでは、URL の長さに 128 文字 (属性も含む) の制限がある。この制限によって、URL 書き換えで転送できるデータ サイズが限られる。属性用の領域を確保するには、WebLogic Server でランダムに生成されるセッション ID のサイズをこの属性で制限する。 WAPEnabled 属性を設定して、長さを 52 文字までに制限し、特殊文字の使用を禁止することもできる。詳細については、「URL 書き換えと Wireless Access Protocol (WAP)」を参照。 |
|
tracking-enabled |
true |
HTTP リクエスト間のセッション トラッキングを有効にする。 |
|
cache-size |
1028 |
JDBC とファイル永続セッションのキャッシュ サイズを設定する。 |
|
max-in-memory-sessions |
-1 |
メモリ/レプリケートされたセッションの最大セッション数を設定する。 メモリ内で使用できるサーブレット セッションの上限数をコンフィグレーションする機能がない場合、新しいセッションが作成され続けると、最終的にはサーバでメモリ不足となる。これを回避するため、WebLogic Server では作成されるセッション数に対して、コンフィグレーション可能な制限を設けている。この数を超えると、新しいセッションの作成が試行されるたびに、 メモリ内で使用できるサーブレット セッションの上限をコンフィグレーションするには、この デフォルトは |
cookies-enabled |
true |
セッション クッキーの使用はデフォルトで有効になっているが (推奨)、このプロパティを |
cookie-name |
JSESSIONID |
セッション トラッキング クッキーの名前を定義する。設定しない場合、デフォルトは |
cookie-path |
null |
セッション トラッキング クッキーのパスを定義する。 この属性を設定しない場合、デフォルトは |
cookie-domain |
null |
クッキーが有効になるドメインを指定する。たとえば、 ドメイン名には少なくとも 2 つのコンポーネントが必要である。名前を この属性を設定しない場合、デフォルトは、クッキーを発行したサーバのドメイン。 詳細については、Sun Microsystems の Servlet 仕様の |
cookie-comment |
null |
クッキー ファイル内のセッション トラッキングを行うクッキーを識別するコメントを指定する。 |
cookie-secure |
false |
クッキーを HTTPS 接続でのみ返信するようブラウザに指示する。これにより、クッキー ID が保護され、HTTPS を使用する Web サイトでのみ使用されるようになる。この機能を有効にすると、HTTP でのセッション クッキーは機能しなくなる。 この機能を使用する場合、 |
cookie-max-age-secs |
-1 |
セッション クッキーの有効期間を秒単位で設定する。時間が経過すると、クッキーはクライアントで期限切れになる。 任意の整数を設定可能。デフォルト値は -1 (無制限)。 クッキーの詳細については、「セッションとセッション永続性の使用」を参照。 |
persistent-store-type |
memory |
永続ストレージの方法を次のいずれかに設定する。
|
persistent-store-cookie-name |
WLCOOKIE |
クッキーベースの永続性に使用するクッキーの名前を設定する。 詳細については、「クッキーベースのセッション永続性の使用」を参照。 |
persistent-store-dir |
session_db |
ファイルベースの永続化に使用されるストレージ ディレクトリを指定する。 各セッションのサイズに有効なセッション数をかけたサイズを保存できるだけのディスク スペースを確保する必要がある。セッションのサイズは 各サーバ インスタンスには、コンフィグレーション不要なデフォルトの永続ファイル ストアがある。したがって、ディレクトリが指定されていない場合は、デフォルトのストアが 複数サーバ間で共有しているディレクトリにカスタム永続ストアを作成すると、ファイル永続セッションをクラスタ対応にできる。ただし、その場合はこのディレクトリを手動で作成する必要がある。 |
persistent-store-pool |
なし |
永続ストレージに使用される JDBC 接続プールの名前を指定する。 |
persistent-store-table |
wl_servlet_sessions |
JDBC ベースの永続セッションの保存に使用するデータベース テーブル名を指定する。これは
|
|
jdbc-column-name-max-inactive-interval |
|
|
jdbc-connection-timeout-secs |
120 |
注意 : この要素はこのリリースでは非推奨。 WebLogic Server が JDBC 接続をタイムアウトするまでの待ち時間を秒単位で設定する (秒数)。 |
url-rewriting-enabled |
true |
URL 書き換えを有効にする。これによって、セッション ID が URL にエンコーディングされ、クッキーがブラウザで無効の場合にセッション トラッキングが実行される。 |
|
http-proxy-caching-of-cookies |
true |
"Cache-control: no-cache=set-cookie" これは、プロキシ キャッシュでクッキーがキャッシュされないことを示す。 |
encode-session-id-in-query-params |
false |
最新の Servlet 仕様では、パス パラメータのセッション ID をコンテナでエンコードする必要があるとされているが、Web サーバの中にはパス パラメータを上手く処理できないものもある。このような場合、 |
|
|
例 : この要素は、さまざまなセッションのセッション実行時情報をタグ付けする場合に役立つ。 |
jsp-descriptor 要素には、JSP コンパイラのコンフィグレーション パラメータのリストを指定します。次の表で、jsp-descriptor 要素内に定義できる要素について説明します。
表 B-8 jsp-descriptor 要素
| 要素 | デフォルト値 | 説明 |
|---|---|---|
page-check-seconds |
1 |
JSP ファイルが変更されたために再コンパイルする必要があるかどうかをチェックする間隔を秒単位で設定する。変更されている場合は、依存関係もチェックされ、再帰的に再ロードされる。
JSP を変更することが稀なプロダクション環境では、チューニング要件に応じて、pageCheckSeconds の値を 60 以上に設定することを検討のこと。 |
precompile |
false |
true に設定すると、Web アプリケーションのデプロイ (再デプロイ) 時または WebLogic Server の起動時に、変更されたすべての JSP が自動的にあらかじめコンパイルされる。 |
precompile-continue |
false |
true に設定すると、いずれかの JSP のコンパイルに失敗しても、変更されたすべての JSP がプリコンパイルされる。precompile が true に設定されている場合にのみ有効。 |
keepgenerated |
false |
JSP コンパイル プロセスの間に生成される Java ファイルを保存する。このパラメータを |
verbose |
true |
|
working-dir |
内部に生成されるディレクトリ |
WebLogic Server が、JSP 用に生成された Java とコンパイル済みのクラス ファイルを保存するディレクトリの名前。 |
print-nulls |
null |
false に設定すると、"null" を含む式は " " として出力される。 |
backward-compatible |
true |
詳細については、「下位互換性フラグ」を参照。 |
encoding |
ユーザのプラットフォームのデフォルト エンコーディング |
JSP ページで使用されるデフォルトの文字セットを指定する。標準の Java 文字セット名を使用する ( この属性を設定しない場合、デフォルトはユーザのプラットフォームのエンコーディング。 JSP コードに含まれる JSP ページ ディレクティブはこの設定をオーバーライドする。次に例を示す。
|
package-prefix |
jsp_servlet |
すべての JSP ページのコンパイル先となるパッケージのプレフィックスを指定する。 |
exact-mapping |
true |
true の場合、JSP の最初の要求時に新しく作成される JspStub が正確な要求にマップされる。exactMapping が false に設定されている場合、Web アプリケーション コンテナは JSP 用に正確ではない url マッピングを生成する。 |
default-file-name |
true |
JSP 用の生成済み Java およびコンパイル済みクラス ファイルを保存するファイルのデフォルト名。 |
rtexprvalue-jsp-param-name |
false |
|
optimize-java-expression |
false |
true の場合、JSP コンパイラにより Java 式が最適化され実行時のパフォーマンスが改善する。 |
compress-html-template |
false |
true の場合、JSP テンプレート ブロック内の HTML が圧縮され実行時のパフォーマンスが改善する。 JSP の HTML テンプレート ブロックに |
auth-filter 要素は、認証フィルタの HttpServlet クラスを指定します。
|
注意 : この要素は現在のリリースでは非推奨とされています。代わりにサーブレット認証フィルタを使用してください。 |
<container-descriptor> 要素には、Web アプリケーションの動作に影響するパラメータのリストを指定します。
<check-auth-on-forward/> 要素は、サーブレットまたは JSP から転送された要求の認証を必要とするときに追加します。再認証を必要としない場合、このタグは省略します。次に例を示します。
<container-descriptor> <check-auth-on-forward/> </container-descriptor>
|
注意 : ベスト プラクティスとしては、check-auth-on-forward プロパティを有効にしないことをお勧めします。 |
<filter-dispatched-requests-enabled> 要素は、ディスパッチされた要求にフィルタを適用するかどうかを制御します。デフォルト値は false です。
|
注意 : 2.4 サーブレットは、(2.4 仕様に従って) 2.3 サーブレットと下位互換性があるため、2.3 の記述子要素が WebLogic Server で検出された場合、<filter-dispatched-requests-enabled> 要素のデフォルトは true になります。 |
<redirect-with-absolute-url> 要素は、javax.servlet.http.HttpServletResponse.SendRedirect() メソッドでのリダイレクトに相対 URL と絶対 URL のどちらを使用するかを制御します。プロキシ HTTP サーバを使用しており、URL を非相対リンクに変換したくない場合は、この要素を false に設定します。
デフォルトの動作では、URL が非相対リンクに変換されます。
|
注意 : リダイレクトで使用されるユーザが読めるデータ。 |
<index-directory-enabled> 要素は、適切なインデックス ファイルが見つからない場合に HTML ディレクトリのリストを自動的に生成するかどうかを制御します。
デフォルト値は false です (ディレクトリは生成されません)。値は true または false です。
<index-directory-sort-by> 要素は、weblogic.servlet.FileServlet で生成されるディレクトリ リストのソート順序を定義します。有効な sort-by 値は、NAME、LAST_MODIFIED、および SIZE です。デフォルトの sort-by 値は NAME です。
<servlet-reload-check-secs> 要素は、サーブレットが変更されたかどうかを WebLogic Server がチェックして、変更されていた場合に再ロードするかどうかを定義します。
値 -1 の場合、サーブレットのチェックは行われない。この値は、プロダクション環境でのデフォルト値です。
値 0 の場合、サーブレットは常にチェックされる。
値 1 の場合、サーブレットは毎秒チェックされる。この値は、開発環境でのデフォルト値です。
コンソールで指定する値は、手動で設定する値よりも常に優先されます。
<resource-reload-check-secs> 要素は、Web アプリケーション スコープのリソース パスで検出されるキャッシュされたリソースのメタデータ キャッシングに使用されます。このパラメータでは、リソースが変更されているかどうかをチェックして変更されていた場合に再ロードを行う頻度を特定します。
値 -1 の場合、再ロードは行われない。この値は、プロダクション環境でのデフォルト値です。
値 0 の場合、常に再ロードが行われる。
値 1 の場合、毎秒再ロードが行われる。この値は、開発環境でのデフォルト値です。
このパラメータの値としては Administration Console を使用して指定したものに優先権が与えられます。
<single-threaded-servlet-pool-size> 要素は、SingleThreadMode インスタンス プールで使用するプールのサイズを定義します。デフォルト値は 5 です。
|
注意 : SingleThreadMode インスタンス プールはこのリリースでは非推奨とされています。 |
<session-monitoring-enabled> 要素を true に設定すると、セッションの実行時 MBean を作成できます。false (デフォルト値) に設定すると、実行時 MBean は作成されません。コンソールで指定する値は、手動で設定する値よりも優先されます。
<save-sessions-enabled> 要素は、再デプロイまたはアンデプロイ時にセッション データをクリーンアップするかどうかを制御します。これはメモリとレプリケート セッションに影響します。値を true に設定すると、セッション データは保存されます。false に設定すると、Web アプリケーションが再デプロイまたはアンデプロイされるときにセッション データは破棄されます。デフォルトは false です。
<prefer-web-inf-classes> 要素を true に設定すると、Web アプリケーションの WEB-INF ディレクトリ内のクラスが、アプリケーションまたはシステム クラスローダにロードされるクラスよりも優先してロードされます。デフォルト値は false です。コンソールで指定する値は、手動で設定する値よりも優先されます。
<default-mime-type> 要素のデフォルト値は null です。この要素を使用すると、拡張がマップされていない content-type のデフォルトの MIME タイプを指定できます。
<client-cert-proxy-enabled> 要素のデフォルト値は true です。true の場合、WebLogic Server によってクライアントからの ID 証明書がバックエンドのサーバに渡されます。また、受信した WL-Proxy-Client-Cert ヘッダを受け入れるのか、破棄するのかが WebLogic Server に通知されます。
WL-Proxy-Client-Cert ヘッダの各 ID 証明書はプロキシサーバ プラグインによってエンコードされ、バックエンドの WebLogic Server インスタンスに渡されます。各 WebLogic Server インスタンスでは、このヘッダから証明書情報を受け取り、安全なソースに由来するものであると確認してから、その証明書情報でユーザを認証します。バックグラウンドの WebLogic Server インスタンスでは、このパラメータが (クラスタ、サーバ、または Web アプリケーションのレベルで) true に設定されている必要があります。
この要素を true に設定する場合、weblogic.security.net.ConnectionFilter を使用して、各 WebLogic Server インスタンスで確実に、プロキシサーバ プラグインが実行されているマシンからの接続のみを受け付けるようにします。true を指定した場合に接続フィルタを使用しないと WL-Proxy-Client-Cert ヘッダのなりすましが可能になるため、セキュリティに脆弱性が生じるおそれがあります。
<relogin-enabled> 要素は下位互換性のためのパラメータです。すでにログインしているユーザが特権を持たないリソースにアクセスしようとすると、応答として FORBIDDEN (403) が発生します。
Web アプリケーションの web.xml 記述子に定義されている security-constraints 要素の中では、auth-constraint 要素が、当該リソースの集合へのアクセスを許可する必要があるユーザ ロールを示します。role-name = "*" とすると、Web アプリケーション内のすべてのロールを示す構文を簡単に記述できます。なお、role-name = "*" は以前のリリースでは、レルム内に定義されているすべてのユーザおよびロールを示すものとして扱われていました。
この allow-all-roles 要素は、以前の動作に戻すための下位互換性スイッチです。デフォルトの動作では、Web アプリケーションに定義されているすべてのロールが許可されます。weblogic-xml に指定されている値が、WebAppContainerMBean に定義されている値よりも優先されます。
weblogic.servlet.FileServlet (暗黙的に登録されているデフォルトのサーブレット) で静的ファイルを提供しているときにネイティブ I/O を使用するには、native-io-enabled を true に設定します (デフォルトは false)。native-io-enabled 要素は Windows 上でのみ適用されます。
minimum-native-file-size 要素は native-io-enabled が true に設定されている場合にのみ適用されます。この要素には、ネイティブ I/O を使用する際の最小ファイル サイズをバイト単位で指定します。提供するファイルのサイズがこの値よりも大きいと、ネイティブ I/O が使用されます。この値を設定しない場合、デフォルト値として 4000 が使用されます。
disable-implicit-servlet-mappings フラグが true に設定されている場合、Web アプリケーション コンテナでは内部サーブレット (*.jsp、*.class など) の暗黙的なマッピングが作成されず、デフォルト サーブレットのマッピングのみが作成されます。通常、暗黙的なサーブレット マッピングを無効にするのは、HttpClusterServlet や HttpProxyServlet をコンフィグレーションしている場合です。
デフォルト値は false です。
optimistic-serialization が有効になっている場合、リクエストがサーブレット コンテキストを超えてディスパッチされるときに getAttribute(name) のコンテキストとリクエスト属性はシリアライズおよびデシリアライズされません。
つまり、複数の Web アプリケーションに共通する属性は、共通の親クラスローダにスコープ指定するか (アプリケーション スコープ指定)、2 つの Web アプリケーションが同じアプリケーションに属していない場合はシステムのクラスパスに配置する必要があります。
optimistic-serialization がオフ (デフォルト値) になっている場合、WebLogic Server は ClassCastException の発生を回避するために getAttribute(name) のコンテキストおよびリクエストの属性をシリアライズおよびデシリアライズします。
optimistic-serialization 値は、WebAppContainerMBean でドメイン レベルで指定することもでき、その場合すべての Web アプリケーションに適用されます。weblogic.xml に値を指定した場合、その値によってドメイン レベルの値がオーバーライドされます。
デフォルト値は false です。
require-admin-trafffic 要素は、トラフィックが管理チャネルを通過する必要があるかどうかを定義します。true に設定すると、トラフィックが管理チャネルを通過できます。true でない場合、トラフィックが管理チャネルを通過できるのは、Web アプリケーションが管理モードにある場合のみです。次に例を示します。
<container-descriptor> <require-admin-traffic>true</require-admin-traffic> </container-descriptor>
<charset-params> 要素は、Unicode 以外の処理でコード セット動作を定義するために使います。次に例を示します。
<charset-params> <input-charset> <resource-path>/*</resource-path> <java-charset-name>UTF-8</java-charset-name> </input-charset> </charset-params>
<input-charset> 要素を使って、GET データと POST データの読み取りにどの文字セットを使用するのかを定義します。次に例を示します。
<input-charset> <resource-path>/foo</resource-path> <java-charset-name>SJIS</java-charset-name> </input-charset>
詳細については、「HTTP リクエストのエンコーディングの識別」を参照してください。
次の表では、<input-charset> 要素内で定義できる要素について説明します。
<charset-mapping> 要素を使って、IANA 文字セット名を Java 文字セット名にマップします。次に例を示します。
<charset-mapping> <iana-charset-name>Shift-JIS</iana-charset-name> <java-charset-name>SJIS</java-charset-name> </charset-mapping>
詳細については、「IANA 文字セットの Java 文字セットへのマッピング」を参照してください。
次の表では、<charset-mapping> 要素内で定義できる要素について説明します。
virtual-directory-mapping 要素は、特定の種類の要求 (画像要求など) 用に、Web アプリケーションのデフォルト ドキュメント ルート以外のドキュメント ルートを指定するために使用します。Web アプリケーション セット用のすべての画像は単一の場所に格納することができ、それらを使用する各 Web アプリケーションのドキュメント ルートにコピーする必要がありません。要求を受信した場合、仮想ディレクトリが指定されていれば、サーブレット コンテナは要求されたリソースをまず仮想ディレクトリで検索し、次に Web アプリケーションのデフォルト ドキュメント ルートで検索します。これにより、同じドキュメントが両方の場所に存在する場合の優先順位が決まります。
次に例を示します。
<virtual-directory-mapping> <local-path>c:/usr/gifs</local-path> <url-pattern>/images/*</url-pattern> <url-pattern>*.jpg</url-pattern> </virtual-directory-mapping> <virtual-directory-mapping> <local-path>c:/usr/common_jsps.jar</local-path> <url-pattern>*.jsp</url-pattern> </virtual-directory-mapping>
次の表では、virtual-directory-mapping 要素内で定義できる要素について説明します。
表 B-11 virtual-directory-mapping 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<local-path> |
必須 |
ディスク上の物理位置を指定する。 |
|
<url-pattern> |
必須 |
マッピングの URL パターンを含む。Servlet API 仕様のセクション 11.2 で指定されているルールに準拠している必要がある。 |
仮想ディレクトリ マッピングの WebLogic Server 実装では、マッピングの url-pattern に一致するディレクトリが必要です。上記の画像の例であれば、c:/usr/gifs/images に images というディレクトリを作成する必要があります。これにより、サーブレット コンテナが images ディレクトリにある複数の Web アプリケーションの画像を見つけることが可能になります。
この要素は、URL パターン マッチング用のクラスを指定するために使用します。WebLogic Server のデフォルト URL マッチ マッピング クラスは J2EE 仕様に基づく weblogic.servlet.utils.URLMatchMap です。また、WebLogic Server には SimpleApacheURLMatchMap も実装されています。これは、url-match-map 要素を使用してプラグインできます。
SimpleApacheURLMatchMap のルールを示します。
*.jws を JWSServlet にマップする場合、
http://foo.com/bar.jws/baz は pathInfo = baz を使用して JWSServlet に解決されます。
次の例に示すように、使用する URLMatchMap を weblogic.xml でコンフィグレーションします。
<url-match-map> weblogic.servlet.utils.SimpleApacheURLMatchMap </url-match-map>
security-permission 要素は、セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。Sun のセキュリティ パーミッション仕様の実装については、次の URL を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
オプションの codebase および signedBy 句は無視してください。
次に例を示します。
<security-permission-spec>
grant { permission java.net.SocketPermission "*", "resolve" };
</security-permission-spec>
各値の説明は次のとおりです。
context-root 要素は、このスタンドアロン Web アプリケーションのコンテキスト ルートを定義します。Web アプリケーションがスタンドアロンではなく EAR の一部の場合、EAR の META-INF/application.xml ファイルにコンテキスト ルートを指定します。application.xml の context-root 設定は、weblogic.xml の context-root 設定に優先します。
この weblogic.xml 要素は、2 フェーズ デプロイメント モデルを使用するデプロイメントに対してのみ有効に機能します。
Web アプリケーションのコンテキスト ルートの優先順位は次のとおりです。
application.xml のコンテキスト ルートがチェックされ、見つかった場合はこれが Web アプリケーションのコンテキスト ルートとして使用される。
コンテキスト ルートの設定が application.xml になく、Web アプリケーションが EAR の一部としてデプロイされる場合、コンテキスト ルートが weblogic.xml に定義されているかどうかがチェックされる。見つかった場合、これが Web アプリケーションのコンテキスト ルートとして使用されます。Web アプリケーションがスタンドアロンとしてデプロイされる場合、application.xml は使用されず、コンテキスト ルートのチェックは weblogic.xml で開始されます。このファイルに定義されていない場合、デフォルトによって URI が使用されます。
コンテキスト ルートが weblogic.xml と application.xml のどちらにも定義されていない場合、コンテキスト パスは URI から推定され、URI に定義されている値から WAR サフィックスを取り除いた名前が付けられる。たとえば、URI が MyWebApp.war の場合は、MyWebApp という名前が付けられます。
|
注意 : context-root 要素を EAR ライブラリ内の個々の Web アプリケーションに対して設定することはできません。Web アプリケーション ライブラリに対してのみ設定できます。 |
wl-dispatch-policy 要素を使用して、ワーク マネージャ名を指定し、Web アプリケーションをコンフィグレーションされたワーク マネージャに割り当てます。この Web アプリケーション レベルのパラメータは、個々のサーブレットや jsp レベルで per-servlet-dispatch-policy 要素を使ってオーバーライドできます。
servlet-descriptor 要素を使用して、サーブレット固有の要素を集約します。
次の表では、servlet-descriptor 要素内で定義できる要素について説明します。
表 B-12 servlet-descriptor 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<servlet-name> |
必須 |
|
<run-as-principal-name> |
省略可能 |
|
<init-as-principal-name> |
省略可能 |
サーブレットの |
<destroy-as-principal-name> |
省略可能 |
サーブレットの |
<dispatch-policy> |
省略可能 |
この要素は非推奨。実行キュー名を指定して、ある特定のサーブレットを割り当てるためにコンフィグレーションされた |
work-manager 要素は <weblogic-web-app> 要素の下位要素です。work-manager 要素の内部には以下の要素を定義できます。
表 B-13 work-manager 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
|
name |
必須 |
ワーク マネージャの名前を指定する。 |
|
response-time-request-class / fair-share-request-class / context-request-class / request-class-name |
省略可能 |
以下の 4 つの要素から選択できる。
|
|
min-threads-constraint、min-threads-constraint-name |
省略可能 |
以下の 2 つの要素から選択できる。
|
|
max-threads-constraint、max-threads-constraint-name |
省略可能 |
以下の 2 つの要素から選択できる。
|
|
capacity、capacity-name |
省略可能 |
以下の 2 つの要素から選択できる。
|
logging 要素は <weblogic-web-app> 要素の下位要素です。logging 要素の内部には以下の要素を定義できます。
表 B-14 logging 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
|
log-filename |
必須 |
ログ ファイルの名前を指定する。ファイル名は絶対アドレスで指定する必要がある。 |
|
logging-enabled |
省略可能 |
この値を指定しないと、WebLogic Server では定義されているデフォルト値が使用される。 値の範囲 : デフォルト値 : |
|
rotation-type |
省略可能 |
ファイルのローテーション タイプを設定する。 指定できる値は
デフォルト値 : |
|
number-of-files-limited |
省略可能 |
当該サーバ インスタンスで、古いメッセージの保存用に作成するファイルの数を制限するかどうかを指定する (
値の範囲 : デフォルト値 : |
|
file-count |
省略可能 |
サーバがログをローテーションする際に作成するログ ファイルの最大数。この数には、現在のメッセージを格納するためにサーバで使用されているファイルは含まれない ( デフォルト値 : |
|
file-size-limit |
省略可能 |
サーバがログ メッセージを別のファイルに移動するきっかけとなるサイズ ( デフォルト値 : |
|
rotate-log-on-startup |
省略可能 |
起動サイクル中にサーバがログ ファイルをローテーションするかどうかを指定する。 値の範囲 : デフォルト値 : |
|
log-file-rotation-dir |
省略可能 |
ローテーションされたログ ファイルが格納されるディレクトリ パスを指定する。 |
|
rotation-time |
省略可能 |
ログ ファイルの時間ベースのローテーション シーケンスの開始時間。フォーマットは 指定した時間がすでに過ぎている場合、サーバは直ちにファイルのローテーションを開始する。 デフォルトでは、ローテーション サイクルは直ちに開始される。 |
|
file-time-span |
省略可能 |
古いログ メッセージが別のファイルに移される間隔 (単位は時間)。 デフォルト値 : |
library-ref 要素では、現在の Web アプリケーションの Web アプリケーション ライブラリとして使用されるライブラリ モジュールを参照します。
次に例を示します。
<library-ref> <library-name>WebAppLibraryFoo</library-name> <specification-version>2.0</specification-version> <implementation-version>8.1beta</implementation-version> <exact-match>false</exact-match> </library-ref>
Web アプリケーションに関連する下位要素は library-name、specification-version、implementation-version、および exact-match のみです。
library-ref 要素の内部には以下の要素を定義できます。
次の表で、fast-swap 要素内に定義できる要素について説明します。
FastSwap デプロイメントの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「FastSwap デプロイメントによる再デプロイメントの最小化」を参照してください。
表 B-16 fast-swap 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<enabled> |
省略可能 |
|
<refresh-interval> |
省略可能 |
FastSwap によって、HTTP リクエストの受信時に、アプリケーション クラスでの変更がチェックされる。 |
<redefinition-task-limit> |
省略可能 |
FastSwap のクラスの再定義は、再定義タスクによって非同期に行われる。再定義タスクは、JMX インタフェースを使用して制御および検査できる。 この要素では、FastSwap システムで保持される再定義タスクの数を指定する。この制限をタスク数が超えると、古いタスクが自動的に削除される。 |
WebLogic Server では、WebLogic Server 9.2 以前のリリースに対する下位互換性は jsp-descriptor 要素の backward-compatible 要素を介してサポートされます。
JSP 2.1 は WebLogic Server 10.0 からサポートされています。Web アプリケーションのバージョン (バージョン 2.4 または 2.5) と weblogic.xml 記述子ファイルの backward-compatible 要素の設定によっては、JSP 2.0 も Weblogic Server でサポートされます。
Web アプリケーションのバージョンが 2.5 であり (つまり、web.xml に 2.5 のバージョン属性があり)、backward-compatibility フラグが false に設定されている場合、
バージョン 2.1 のすべての JSP/TAG ファイルは新しい JSP 動作に従う。
バージョン 2.0 以前のすべての JSP/TAG ファイルは JSP 2.0 以前の動作に従う。
Web アプリケーションのバージョンが 2.5 であり、backward-compatibility フラグが true に設定されている場合、すべての JSP/TAG ファイルは JSP 2.0 以前の動作に従う。
Web アプリケーションのバージョンが 2.4 以前である場合は、backward-compatibility フラグの設定に関係なく、すべての JSP/TAG ファイルは JSP 2.0 以前の動作に従う。
Servlet 2.5 仕様では、java.lang.*、javax.servlet.*、javax.servlet.jsp.*、および javax.servlet.http.* パッケージのみが暗黙的にインポートされると規定されています。Servlet 2.5 仕様に準拠して、WebLogic Server ではこれらの規定されているパッケージのみがインポートされます。一方、WebLogic Server の以前のリリースでは、java.io.*、java.util.*、および javax.servlet.jsp.tagext.* パッケージもインポートされていました。
以下のいずれかの状態である場合、WebLogic Server は 2.4 以前の動作に従い、上記の規定されていないパッケージもインポートします。
weblogic.xml 記述子ファイルの backward-compatibility フラグが true に設定されている。
Web アプリケーションのバージョンが 2.4 以前である。
バージョン 2.5 の Web アプリケーションにある個々の JSP/TAG ファイルがバージョン 2.0 以前である。
Web コンテナをグローバル レベルでコンフィグレーションするには、WebAppContainerMBean を使用します。WebAppContainerMBean 属性の詳細と、この属性を使用してすべての Web アプリケーションに対しドメイン全体のデフォルトを指定する方法については、「WebAppContainerMBean」を参照してください。
