Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSP の開発 12c (12.2.1.3.0) E90351-03 |
|
前 |
次 |
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.8/weblogic-web-app.xsd
を参照してください。
async-descriptor
要素を使用して、Webアプリケーションの非同期処理動作を構成します。次の表では、async-descriptor
要素内で定義できる要素について説明します。
表B-1 async-descriptor要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
timeout-secs |
省略可能 |
WebLogic Serverで非同期ジョブがタイムアウトになるまでに待機する時間を秒単位で設定します。デフォルト値は120秒です。 タイムアウトを |
timeout-check-interval-secs |
省略可能 |
WebLogic Serverでタイムアウト・ジョブのチェックを行う間隔の待機時間を秒単位で設定します。デフォルト値は30秒です。 |
async-work-manager
要素を使用して、非同期ジョブ(AsyncContext
dispatch
メソッドを使用して開始される非同期ディスパッチや、AsyncContext
start
メソッドを使用して開始される実行可能ジョブなど)にワーク・マネージャを指定します。ワーク・マネージャが指定されていない場合、非同期ジョブは現在のリクエスト・ワーク・マネージャで実行されます。
auth-filter
要素は、認証フィルタのHttpServletクラスを指定します。
注意:
この要素は現在のリリースでは非推奨とされています。かわりにサーブレット認証フィルタを使用してください。
charset-params
要素は、Unicode以外の処理のコード・セット動作を定義するために使用します。例:
<charset-params> <input-charset> <resource-path>/*</resource-path> <java-charset-name>UTF-8</java-charset-name> </input-charset> </charset-params>
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
要素内で定義できる要素について説明します。
表B-2 charset-mapping要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
iana-charset-name |
必須 |
|
java-charset-name |
必須 |
使用するJava文字セットを指定します。 |
input-charset
要素を使用して、GET
データとPOST
データの読取りに使用する文字セットを定義します。例:
<input-charset> <resource-path>/foo</resource-path> <java-charset-name>SJIS</java-charset-name> </input-charset>
「HTTPリクエストのエンコーディングの識別」を参照してください。
次の表では、input-charset
要素内で定義できる要素について説明します。
表B-3 input-charset要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
resource-path |
必須 |
このパスがリクエストのURLに含まれている場合、 |
java-charset-name |
必須 |
使用するJava文字セットを指定します。 |
container-descriptor
要素には、Webアプリケーションの動作に影響するパラメータのリストを指定します。
access-logging-disabled
要素は、基底のWebアプリケーションのアクセス・ロギングを無効にするかどうかを定義します。このプロパティをtrue
に設定すると、ロギングのオーバーヘッドが小さくなり、サーバーのスループットが改善されます。このプロパティを指定しないかfalse
に設定すると、アプリケーションのアクセスがロギングされます。
Webアプリケーションのweb.xml
記述子に定義されているsecurity-constraints要素の中では、auth-constraint
要素が、当該リソース・コレクションへのアクセスを許可する必要があるユーザー・ロールを示します。role-name = "*"とすると、Webアプリケーション内のすべてのロールを示す構文を簡単に記述できます。なお、role-name = "*"は以前のリリースでは、レルム内に定義されているすべてのユーザーおよびロールを示すものとして扱われていました。
このallow-all-roles
要素は、以前の動作に戻すための後方互換性スイッチです。デフォルトの動作では、Webアプリケーションに定義されているすべてのロールが許可されます。weblogic.xml
に指定されている値が、WebAppContainerMBean
に定義されている値よりも優先されます。
サーブレットまたはJSPから転送されたリクエストの認証を必須にする場合は、check-auth-on-forward
要素を追加します。再認証を必要としない場合、このタグは省略します。例:
<container-descriptor> <check-auth-on-forward/> </container-descriptor>
注意:
ベスト・プラクティスとして、check-auth-on-forward
プロパティを無効にしておくことをお薦めします。
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ヘッダーのなりすましが可能になるため、セキュリティに脆弱性が生じるおそれがあります。
container-initializer-enabled
要素は、サーブレット・コンテナ・イニシャライザを有効化するかどうかを制御します。
サーブレット3.xアプリケーションでは、ServletContainerInitializer
はデフォルトで有効になっています。パフォーマンス上の理由から、ターゲットのWebアプリケーションのweblogic.xml
デプロイメント記述子でcontainer-initializer-enabled
要素を構成することにより、サーブレット・コンテナ・イニシャライザを明示的に無効化できます。例:
<?xml version="1.0" encoding="UTF-8"?> <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3.0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.8/weblogic-web-app.xsd"> ... <container-descriptor> <container-initializer-enabled>false</container-initializer-enabled> </container-descriptor> ... </weblogic-web-app>
サーブレット3.x以前のアプリケーションでは、weblogic.xml
デプロイメント記述子でcontainer-initializer-enabled
要素をtrue
に設定することにより、サーブレット・コンテナ・イニシャライザを明示的に有効化できます。例:
<container-descriptor> <container-initializer-enabled>true</container-initializer-enabled> </container-descriptor>
default-mime-type
要素のデフォルト値はnull
です。この要素を使用すると、拡張がマップされていないcontent-typeのデフォルトのMIMEタイプを指定できます。
disable-implicit-servlet-mappings
フラグがtrue
に設定されている場合、Webアプリケーション・コンテナでは内部サーブレット(*.jsp
、*.class
など)の暗黙的なマッピングが作成されず、デフォルト・サーブレットのマッピングのみが作成されます。通常、暗黙的なサーブレット・マッピングを無効にするのは、HttpClusterServlet
やHttpProxyServlet
を構成している場合です。
デフォルト値はfalse
です。
filter-dispatched-requests-enabled
要素は、ディスパッチされたリクエストにフィルタを適用するかどうかを制御します。デフォルト値はfalse
です。
注意:
(2.4仕様によると)2.4サーブレットは2.3サーブレットと後方互換性があるため、2.3の記述子要素がWebLogic Serverで検出された場合、filter-dispatched-requests-enabled
要素のデフォルトはtrue
になります。
セクション・タイトル
gzip-compression
要素は、指定したWebアプリケーションのGZIP圧縮サポートを制御します。
表B-4 gzip-compressionのサブ要素
要素 | 説明 | デフォルト値 |
---|---|---|
enabled |
指定したWebアプリケーションのGZIP圧縮を有効化します。trueに設定すると、現在のアプリケーションのみが影響を受けます。 指定すると、 |
false |
min-content-length |
指定したWebアプリケーションの圧縮をトリガーする最小ファイル・サイズを指定します。この要素により、圧縮しても効果が小さく、不要なCPUを消費するサイズの小さいリソースを無視できます。 指定すると、 |
2048 |
content-type |
圧縮に含めるコンテンツのタイプを指定します。タイプごとに別々のcontent-typeサブ要素を使用することで、複数のコンテンツ・タイプを指定できます。 指定すると、 |
text/html, text/xml, text/plain |
gzip-compression
要素およびそのすべてのサブ要素がある場合、これらの値はドメイン・レベルであらゆるデフォルト値をオーバーライドします。サブ要素の1つがない場合、その属性のデフォルトのドメイン値が使用されます。
次の例は、gzip-compression
要素およびそのサブ要素の設定を示しています。
<weblogic-web-app> <container-descriptor> <gzip-compression> <enabled>true</enabled> <min-content-length>4096</min-content-length> <content-type>text/html</content-type> <content-type>text/xml</content-type> </gzip-compression> </container-descriptor> </weblogic-web-app>
(オプション) このセクションに参照情報を入力します。
構文
(オプション) ここに構文の情報を入力します。
例B-1 例タイトル
(オプション) ここにリファレンスを示す例を入力します。
index-directory-enabled
要素は、適切な索引ファイルが見つからない場合にHTMLディレクトリのリストを自動的に生成するかどうかを制御します。
デフォルト値はfalse
です(ディレクトリは生成されません)。値はtrue
またはfalse
です。
index-directory-sort-by
要素は、weblogic.servlet.FileServlet
で生成されるディレクトリ・リストのソート順序を定義します。有効なsort-by値は、NAME
、LAST_MODIFIED
、およびSIZE
です。デフォルトのsort-by値はNAME
です。
langtag-revision
要素により、HttpServletRequest
のgetLocale
メソッドとgetLocales
メソッドが従う必要のある言語タグ仕様のバージョンが決定します。
現在、WebLogic ServerではRFC5646およびRFC3066がサポートされています。値を設定しないと、HttpServletRequest
のgetLocale
メソッドとgetLocales
メソッドは、RFC5646に従ってロケールの言語タグを返します。値3066を設定すると、HttpServletRequest
のgetLocale
メソッドとgetLocales
メソッドは、RFC3066に従ってロケールの言語タグを返します。RFC3066の使用例を次に示します。
<container-descriptor> <langtag-revision>3066</langtag-revision> </container-descriptor>
システム・プロパティ-Dweblogic.servlet.langtagRevision
でもロケール解析メカニズムを指定できます。ただし、weblogic.xml
で明示的に構成されたlangtag-revision
要素は、-Dweblogic.servlet.langtagRevision
の構成よりも優先されます。weblogic.xml
に値を設定しないと、システム・プロパティ構成が有効になります。
次の表では、weblogic.xml
のlangtag-revision
要素、システム・プロパティ-Dweblogic.servlet.langtagRevision
、およびRFC3066の動作の関係について説明します。
システム・プロパティ | weblogic.xml | RFC3066動作の使用 |
---|---|---|
未設定/5646 |
未設定/5646 |
無効 |
未設定/5646 |
3066 |
有効 |
3066 |
未設定 |
有効 |
3066 |
5646 |
無効 |
3066 |
3066 |
有効 |
minimum-native-file-size
要素はnative-io-enabled
がtrue
に設定されている場合にのみ適用されます。この要素には、ネイティブI/Oを使用する際の最小ファイル・サイズをバイト単位で指定します。提供するファイルのサイズがこの値よりも大きいと、ネイティブI/Oが使用されます。この値を設定しない場合、デフォルト値として4000
が使用されます。
weblogic.servlet.FileServlet
(暗黙的に登録されているデフォルトのサーブレット)で静的ファイルを提供しているときにネイティブI/Oを使用するには、native-io-enabled
をtrue
に設定します。(デフォルト値はfalse
です。) native-io-enabled
要素はWindows上でのみ適用されます。
optimistic-serialization
が有効になっている場合、リクエストがサーブレット・コンテキストを超えてディスパッチされるときにgetAttribute(name)
のコンテキストとリクエスト属性はシリアライズおよびデシリアライズされません。
つまり、複数のWebアプリケーションに共通する属性は、共通の親クラスローダーにスコープ指定するか(アプリケーション・スコープ指定)、2つのWebアプリケーションが同じアプリケーションに属していない場合はシステムのクラスパスに配置する必要があります。
optimistic-serialization
がオフ(デフォルト値)になっている場合、WebLogic ServerはClassCastExceptionの発生を回避するためにgetAttribute(name)
のコンテキストおよびリクエストの属性をシリアライズおよびデシリアライズします。
optimistic-serialization
値は、WebAppContainerMBean
でドメイン・レベルで指定することもでき、その場合すべてのWebアプリケーションに適用されます。weblogic.xml
に値を指定した場合、その値によってドメイン・レベルの値がオーバーライドされます。
デフォルト値はfalse
です。
prefer-application-packages
要素は、常にアプリケーションからロードする必要のあるクラスに対してパッケージ・リストを指定します。『Oracle WebLogic Serverアプリケーションの開発』のprefer-application-packages
に関する項を参照してください。
<?xml version="1.0" encoding="UTF-8"?> <wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.8/weblogic-web-app.xsd"> <wls:weblogic-version>12.2.1</wls:weblogic-version> <wls:context-root>FilterWeb</wls:context-root> <wls:container-descriptor> <wls:prefer-application-packages> <wls:package-name>com.oracle.foo</wls:package-name> </wls:prefer-application-packages> </wls:container-descriptor> </wls:weblogic-web-app>
prefer-application-packages
またはprefer-application-resources
を使用するためには、prefer-web-inf-classes
をfalseに設定する必要がありますので注意してください。
prefer-application-resources
要素は、リソースがシステム・クラスローダーにある場合を含め、常にアプリケーションからロードする必要があるリソースのリストを指定します。『Oracle WebLogic Serverアプリケーションの開発』のprefer-application-resources
に関する項を参照してください。
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>javax.faces.*</package-name>
<package-name>com.sun.faces.*</package-name>
<package-name>com.bea.faces.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>javax.faces.*</resource-name>
<resource-name>com.sun.faces.*</resource-name>
<resource-name>com.bea.faces.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
</prefer-application-resources>
</container-descriptor>
</weblogic-web-app>
prefer-application-packages
またはprefer-application-resources
を使用するためには、prefer-web-inf-classes
をfalseに設定する必要がありますので注意してください。
転送リクエストでHttpServletRequest.getQueryString()
が呼び出されたとき、WebLogic Serverは、RequestDispatcher経由で転送サーブレットによって送信されたqueryStringとクライアントによって送信されたオリジナルなqueryStringを戻します。
prefer-forward-query-string
フラグをtrue
に設定した場合、WebLogic Serverは、転送された問合せ文字列が指定されている場合、それのみを戻します。デフォルト値はfalse
です。
prefer-web-inf-classes
要素をtrueに設定すると、WebアプリケーションのWEB-INF
ディレクトリにあるクラスが、アプリケーションまたはシステム・クラスローダー内にロードされたクラスに優先してロードされます。デフォルト値はfalse
です。
注意:
weblogic.xml
内でprefer-web-inf-classes
が有効になっている場合、prefer-application-packages
もprefer-application-resources
も指定できません。
redirect-with-absolute-url
要素は、javax.servlet.http.HttpServletResponse.SendRedirect()
メソッドでのリダイレクトに相対URLと絶対URLのどちらを使用するかを制御します。プロキシHTTPサーバーを使用しており、URLを非相対リンクに変換したくない場合は、この要素をfalse
に設定します。
デフォルトの動作では、URLが非相対リンクに変換されます。
注意:
リダイレクトで使用されるユーザーが読めるデータ。
クロスサイト・リクエスト・フォージェリ(CSRF)攻撃を軽減するには、受信HTTPリクエストでRefererヘッダーの検証を構成できます。
Refererのチェックは、ユーザーごとの状態を必要としないため、埋込みネットワーク・デバイスでCSRFを防止するために一般的に使用される方法です。これによって、メモリー不足の際またはサーバー側の状態が存在しないときに、RefererはCSRFを防止するのに便利なメソッドになります。このCSRFを軽減するメソッドも、一般的に未認証リクエスト(同期トークンを追跡するために必要なセッション状態を確立する前に作成されたリクエストなど)で使用されます。
<container-descriptor> <referer-validation>NONE</referer-validation> </container-descriptor>
有効な値:
NONE
: 無効化Refererヘッダー検証を無効化します。
LENIENT
(デフォルト): Webコンテナによって、Refererヘッダーの値が正しくないリクエストはブロックされます。リクエストにヘッダーがない場合、Webコンテナでリクエストが受け付けられます。
STRICT
: Webコンテナによって、Refererヘッダーがないリクエストはブロックされます。
http://myhost:myport/myapp/Jj_security_check
に送信されます。<referer-validation>NONE</referer-validation>
の場合、コンテナはRefererヘッダーを検証しません。
<referer-validation>LENIENT</referer-validation>
で、このリクエストにRefererヘッダーがある場合、コンテナはReferer URLのホストおよびポートをチェックします。
ホストおよびポートが「myhost
」および「myport
」の場合、このRefererヘッダーは有効です。
Referer URLのホストまたはポートのいずれかが実際のURLと異なる場合(たとえば、「myhost1
」)、このRefererヘッダーは無効です。
このリクエストにRefererヘッダーがない場合、コンテナは検証されません。
<referer-validation>STRICT</referer-validation>
で、このリクエストにRefererヘッダーがある場合、コンテナはReferer URLのホストおよびポートをチェックします。
ホストおよびポートが「myhost
」および「myport
」の場合、このRefererヘッダーは有効です。
Referer URLのホストまたはポートのいずれかが実際のURLと異なる場合(たとえば、「myhost1
」)、このRefererヘッダーは無効です。
このリクエストにRefererヘッダーがない場合、検証は失敗します。
注意:
WebコンテナはIPアドレスも考慮します。たとえば、192.168.226.129
が「myhost
」にマップされている場合、Referer URLのホストが「192.168.226.129
」の場合に有効です。relogin-enabled
要素は後方互換性のためのパラメータです。すでにログインしているユーザーが権限を持たないリソースにアクセスしようとすると、FORBIDDEN (403)
レスポンスが発生します。
require-admin-trafffic
要素は、トラフィックが管理チャネルを通過する必要があるかどうかを定義します。true
に設定すると、トラフィックが管理チャネルを通過できます。それ以外の場合、トラフィックが管理チャネルを通過できるのは、Webアプリケーションが管理モードにある場合のみです。例:
<container-descriptor> <require-admin-traffic>true</require-admin-traffic> </container-descriptor>
resource-reload-check-secs
要素は、Webアプリケーション・スコープのリソース・パスで見つかったキャッシュされたリソースに対してメタデータ・キャッシングを実行する場合に使用します。このパラメータでは、リソースが変更されているかどうかをチェックして変更されていた場合に再ロードを行う頻度を特定します。
値-1
の場合、再ロードは行われません。これは、本番環境でのデフォルト値です。
値0
の場合、常に再ロードが行われます。
値1
の場合、毎秒再ロードが行われます。この値は、開発環境でのデフォルト値です。
このパラメータの値としてはWebLogic Server管理コンソールを使用して指定したものに優先権が与えられます。
注意:
リソースがJSPであり、page-check-seconds
がjsp-descriptor
要素内に指定されている場合、page-check-seconds
値を使用してJSPファイルの再ロード時間が決定されます。
save-sessions-enabled
要素は、再デプロイまたはアンデプロイ時にセッション・データをクリーン・アップするかどうかを制御します。これはメモリーとレプリケート・セッションに影響します。値をtrueに設定すると、セッション・データは保存されます。falseに設定すると、Webアプリケーションが再デプロイまたはアンデプロイされるときにセッション・データは破棄されます。デフォルトはfalse
です。
servlet-reload-check-secs
要素は、サーブレットが変更されたかどうかをWebLogic Serverがチェックして、変更されていた場合に再ロードするかどうかを定義します。
値-1
の場合、サーブレットのチェックは行われません。これは、本番環境でのデフォルト値です。
値0
の場合、サーブレットは常にチェックされます。
値1
の場合、サーブレットは毎秒チェックされます。この値は、開発環境でのデフォルト値です。
WebLogic ServerのWebLogic Server管理コンソールで指定した値は、手動で指定する値よりも常に優先されます。
session-monitoring-enabled
要素をtrueに設定すると、セッションに対してランタイムMBeanを作成できます。デフォルト値のfalse
に設定すると、ランタイムMBeansは作成されません。WebLogic Server管理コンソールで指定した値は、手動で設定する値よりも優先されます。
show-archived-real-path-enabled
要素は、アーカイブされたWebアプリケーションのgetRealPath()
の動作を指定します。
true
に設定されている場合、getRealPath()
はリソース・ファイルの標準のパスを戻します。
show-archived-real-path-enabled
要素がfalse
に設定されている場合、サーブレット・コンテナは、アーカイブされたWebアプリケーションのファイルのフルパスをnull
として戻します。
デフォルト値はfalse
です。
single-threaded-servlet-pool-size
要素は、SingleThreadMode
インスタンス・プールに使用されるプールのサイズを定義します。デフォルト値は5
です。
注意:
SingleThreadMode
インスタンス・プールは、このリリースでは非推奨とされています。
context-root
要素は、このスタンドアロンWebアプリケーションのコンテキスト・ルートを定義します。WebアプリケーションがスタンドアロンではなくEARの一部の場合、EARのMETA-INF/application.xml
ファイルにコンテキスト・ルートを指定します。application.xml
のcontext-root
設定は、weblogic.xml
のcontext-root
設定より優先します。
このweblogic.xml
要素は、2フェーズ・デプロイメント・モデルを使用するデプロイメントに対してのみ有効に機能します。
Webアプリケーションのコンテキスト・ルートの優先順位は次のとおりです。
application.xml
のcontext-root
およびweb-uri
のコンテキスト・ルートがチェックされ、見つかった場合は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アプリケーション・ライブラリに対してのみ設定できます。
次の表では、ejb-reference-description
要素内で定義できる要素について説明します。
表B-5 ejb-reference-description要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
ejb-ref-name |
必須 |
Webアプリケーションで使用するEJB参照の名前を指定します。 |
jndi-name |
必須 |
参照のJNDI名を指定します。 |
次の表では、fast-swap
要素内で定義できる要素について説明します。
FastSwapデプロイメントの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。
表B-6 fast-swap要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
enabled |
省略可能 |
|
refresh-interval |
省略可能 |
FastSwapによって、HTTPリクエストの受信時に、アプリケーション・クラスでの変更がチェックされます。 |
redefinition-task-limit |
省略可能 |
FastSwapのクラスの再定義は、再定義タスクによって非同期に行われます。再定義タスクは、JMXインタフェースを使用して制御および検査できます。 この要素では、FastSwapシステムで保持される再定義タスクの数を指定します。この制限をタスク数が超えると、古いタスクが自動的に削除されます。 |
jsp-descriptor
要素には、JSPコンパイラの構成パラメータのリストを指定します。次の表で、jsp-descriptor
要素内に定義できる要素について説明します。
表B-7 jsp-descriptor要素
要素 | デフォルト値 | 説明 |
---|---|---|
page-check-seconds |
1 |
JSPファイルが変更されたために再コンパイルする必要があるかどうかをチェックする間隔を秒単位で設定します。変更されている場合は、依存関係もチェックされ、再帰的に再ロードされます。
JSPを変更することが稀な本番環境では、チューニング要件に応じて、pageCheckSecondsの値を60以上に設定することを検討してください。 |
strict-stale-check |
true |
展開されたWARにのみ適用されます。 更新されたJSPファイルがチェックされます。つまり、ファイルのタイムスタンプがビルド時のタイムスタンプよりも後(新しい)かどうかがチェックされます。新しいファイルが古いファイルを置換できるのみです。 falseに設定した場合は、タイムスタンプが変更されたかどうかのみがチェックされます。変更されていれば、ファイルが置換されます。 <?xml version="1.0" encoding="UTF-8"?> <weblogic-web-app xmlns="http:// xmlns.oracle.com/weblogic/weblogic-web-app"> <jsp-descriptor> <strict-stale-check>false </strict-stale-check> </jsp-descriptor> </weblogic-web-app> |
precompile |
false |
trueに設定すると、Webアプリケーションのデプロイ(再デプロイ)時またはWebLogic Serverの起動時に、すべてのJSPが自動的にあらかじめコンパイルされます。 |
precompile-continue |
false |
trueに設定すると、いずれかのJSPのコンパイルに失敗しても、すべてのJSPがプリコンパイルされます。precompileがtrueに設定されている場合にのみ有効です。 |
keepgenerated |
false |
JSPコンパイル・プロセスの間に生成されるJavaファイルを保存します。このパラメータを |
debug |
false |
デフォルト値は |
verbose |
true |
|
working-dir |
internally generated directory |
WebLogic Serverが、JSP用に生成されたJavaとコンパイル済みのクラス・ファイルを保存するディレクトリの名前。 注意: |
print-nulls |
null |
falseに設定すると、"null"を含む式は" "として出力されます。 |
backward-compatible |
true |
「後方互換性フラグ」を参照してください。 |
encoding |
UTF-8 for JSP and JSPX pages |
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テンプレート・ブロックに |
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
要素の内部には以下の要素を定義できます。
表B-8 library-ref要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
library-name |
必須 |
ライブラリ・モジュールの参照用にライブラリの名前を提供します。デフォルト値は |
specification-version |
省略可能 |
ライブラリ・モジュールの参照用に仕様のバージョンを提供します。デフォルト値は |
implementation-version |
省略可能 |
ライブラリ・モジュールの参照用に実装のバージョンを提供します。デフォルト値は |
exact-match |
省略可能 |
デフォルト値は |
logging
要素はweblogic-web-app
要素の下位要素です。logging
要素の内部には以下の要素を定義できます。
表B-9 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 |
省略可能 |
古いログ・メッセージが別のファイルに移される間隔(単位は時間)。( デフォルト値: |
ReadyAppフレームワークを使用するには、次のコードをアプリケーションのWebLogicデプロイメント記述子(META-INF\weblogic-application.xml
)に追加することでWARベース・アプリケーションをフレームワークに登録します。
<wls:ready-registration>true</wls:ready-registration>
アプリケーションが起動されると、アプリケーションの状態はNOT READYに設定されます。
注意:
接頭辞wls:
は、weblogic-application.xml
ファイルのコンテンツに応じて、必須の場合と必須でない場合があります。残りのタグに接頭辞がない場合には、接頭辞を付ける必要はありません。『Oracle WebLogic Serverへのアプリケーションのデプロイ』のEARまたはWARベースのアプリケーションを使用したReadyAppフレームワークの構成に関する項を参照してください。
resource-description
要素は、サーバー・リソースのJNDI名を、WebLogic ServerのEJBリソースの参照にマップするために使用されます。
次の表では、resource-description
要素内で定義できる要素について説明します。
表B-10 resource-description要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
res-ref-name |
必須 |
リソース参照名を指定します。 |
jndi-name |
必須 |
リソースのJNDI名を指定します。 |
resource-env-description
要素は、ejb-jar.xml
デプロイメント記述子で宣言されたresource-env-ref
を、それが表しているサーバー・リソースのJNDI名にマップします。
次の表では、resource-env-description
要素内で定義できる要素について説明します。
表B-11 resource-env-description要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
res-env-ref-name |
必須 |
リソース環境参照名を指定します。 |
jndi-name |
必須 |
リソース環境参照のJNDI名を指定します。 |
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
要素内で定義できる要素について説明します。
表B-12 run-as-role-assignment要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
role-name |
必須 |
セキュリティ・ロール名を指定します。 |
run-as-principal-name |
必須 |
プリンシパルの名前を指定します。 |
security-permission
要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ権限を指定します。セキュリティ権限仕様の実装については、http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html
を参照してください。
オプションのcodebase
およびsignedBy
句は無視してください。
例:
<security-permission-spec> grant { permission java.net.SocketPermission "*", "resolve" }; </security-permission-spec>
説明:
permission java.net.SocketPermission
は許可・クラス名。
"*"
はターゲット名。
resolve
はアクション。
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-13 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アプリケーション・コンテナによって暗黙的なマッピングが作成され、ログに警告メッセージが出力されます。
次の表では、service-reference-description
要素内で定義できる要素について説明します。
表B-14 service-reference-description要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
service-ref-name |
||
wsdl-url |
||
call-property |
|
|
port-info |
|
servlet-descriptor
要素を使用して、サーブレット固有の要素を集約します。
次の表では、servlet-descriptor
要素内で定義できる要素について説明します。
表B-15 servlet-descriptor要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
servlet-name |
必須 |
|
run-as-principal-name |
省略可能 |
|
init-as-principal-name |
省略可能 |
サーブレットの |
destroy-as-principal-name |
省略可能 |
サーブレットの |
dispatch-policy |
省略可能 |
この要素は非推奨です。ワーク・マネージャ名を識別することにより、特定のサーブレットを、構成されたワーク・マネージャに割り当てるために使用されます。この設定は、 |
次の表では、サーブレット・セッションのパラメータを定義するためにsession-descriptor
要素内で定義できる要素について説明します。
表B-16 session-descriptor
要素名 | デフォルト値 | 値 |
---|---|---|
timeout-secs |
|
WebLogic Serverでセッションをタイムアウトするまでに待機する時間を秒単位で指定します。デフォルト値は3600秒です。 トラフィックの多いサイトでは、セッションのタイムアウトを調整すると、アプリケーションの動作を最適化できます。ブラウザ・クライアントでいつでもセッションを終了できるようにする必要がある場合でも、ユーザーがサイトを離れるか、ユーザーのセッションがタイムアウトになれば、サーバーに接続する必要はなくなります。 この属性は、 |
invalidation-interval-secs |
60 |
WebLogic Serverが、タイムアウトの無効なセッションに対してハウス・クリーニング・チェックを実行してから古いセッションを削除してメモリーを解放するまでの待機時間を秒単位で設定します。この要素を使用して、トラフィックの多いサイトでWebLogic Serverのパフォーマンスが最適化されるようにチューニングします。 デフォルト値は60秒です。 |
invalidate-on-relogin |
false |
現在ログインしているユーザーが別のユーザー名(セキュリティ・レルムで有効なもの)に切り替えて再ログインを試みた場合に、コンテナで現在のセッションを無効にするかどうかを設定します。 このパラメータの値を |
sharing-enabled |
|
アプリケーション・レベルでこの値を Webアプリケーション・レベルで有効になっている場合、この要素は無視されます。 |
debug-enabled |
|
HTTPセッションのデバッグ機能を有効にします。 デフォルト値は |
id-length |
|
セッションIDのサイズを設定します。 最小値は32バイト、最大値は 注意: 32バイト未満の値を設定すると、WebLogic Serverでは値が自動的に32に上げられ、次のメッセージが表示されます。 The IDLength is too short. It is not secure. WLS will raise the length to 32. WAPアプリケーションを作成する場合、WAPプロトコルはCookieをサポートしていないため、URLを書き換える必要があります。また、一部のWAPデバイスでは、URLの長さに128文字(属性も含む)の制限があり、URL書換えで転送できるデータ・サイズが限られます。属性用の領域を確保するには、WebLogic Serverでランダムに生成されるセッションIDのサイズをこの属性で制限します。 WAPEnabled属性を設定して、長さを52文字までに制限し、特殊文字の使用を禁止することもできます。「URL書換えとWireless Access Protocol (WAP)」を参照してください。 |
tracking-enabled |
|
HTTPリクエスト間のセッション・トラッキングを有効にします。 |
cache-size |
|
JDBCとファイル永続セッションのキャッシュ・サイズを設定します。 |
max-in-memory-sessions |
|
メモリー/レプリケートされたセッションの最大セッション数を設定します。 メモリー内で使用できるサーブレット・セッションの上限数を構成する機能がない場合、新しいセッションが作成され続けると、最終的にはサーバーでメモリー不足となります。これを回避するため、WebLogic Serverでは作成されるセッション数に対して、構成可能な制限を設けています。この数を超えると、新しいセッションの作成が試行されるたびに、 メモリー内で使用できるサーブレット・セッションの上限を構成するには、この デフォルトは |
max-save-post-size |
|
FORM認証時にコンテナが保存/バッファするPOSTデータの最大サイズをバイト単位で設定します。 デフォルト値は |
save-post-timeout-secs |
|
POSTデータを保存/バッファしたセッションのタイムアウトを秒単位で定義します。FORM認証の場合、POSTデータはセッション内に保存され、ユーザーはログイン・フォームにリダイレクトされます。 デフォルト値は
|
save-post-timeout-interval-secs |
|
POSTデータをセッションに保存する際の、無効化トリガーの間隔を秒単位で設定します。 デフォルト値は |
cookies-enabled |
true |
セッションCookieの使用はデフォルトで有効になっているが(推奨)、このプロパティを |
cookie-name |
JSESSIONID |
セッション・トラッキングCookieの名前を定義します。設定しない場合、デフォルトは |
cookie-path |
|
セッション・トラッキングCookieのパスを定義します。 この属性を設定しない場合、デフォルトは |
cookie-domain |
|
Cookieが有効になるドメインを指定します。たとえば、 ドメイン名には少なくとも2つのコンポーネントが必要です。名前を この属性を設定しない場合、デフォルトは、Cookieを発行したサーバーのドメイン。 Servlet仕様の |
cookie-comment |
|
Cookieファイル内のセッション・トラッキングを行うCookieを識別するコメントを指定します。 |
cookie-secure |
false |
CookieをHTTPS接続でのみ返信するようブラウザに指示します。これにより、Cookie IDが保護され、HTTPSを使用するWebサイトでのみ使用されるようになります。この機能を有効にすると、HTTPでのセッションCookieは機能しなくなります。 この機能を使用する場合、 |
cookie-max-age-secs |
-1 |
セッションCookieの存続期間を秒単位で設定します。時間が経過すると、Cookieはクライアントで期限切れになります。 任意の整数を設定可能です。デフォルト値は -1 (無制限)。 Cookieの詳細は、「セッションとセッション持続性の使用」を参照してください。 |
persistent-store-type |
memory |
永続ストレージの方法を次のいずれかに設定します。
|
persistent-store-cookie-name |
WLCOOKIE |
Cookieベースの永続性に使用するCookieの名前を設定します。 「Cookieベースのセッション永続性の使用」を参照してください。 |
persistent-store-dir |
session_db |
ファイル・ベースの永続性に直接使用されるストレージ・ディレクトリを指定します 各セッションのサイズに有効なセッション数をかけたサイズを保存できるのみのディスク・スペースを確保する必要があります。セッションのサイズは 各サーバー・インスタンスには、構成不要なデフォルトの永続ファイル・ストアがあります。したがって、ディレクトリが指定されていない場合は、デフォルトのストアが 複数サーバー間で共有しているディレクトリにカスタム永続ストアを作成すると、ファイル永続セッションをクラスタリング可能にできます。ただし、その場合はこのディレクトリを手動で作成する必要があります。 |
persistent-store-pool |
None |
永続ストレージに使用されるJDBC接続プールの名前を指定します。 |
persistent-data-source-jndi-name |
None |
|
persistent-store-table |
wl_servlet_sessions |
JDBCベースの永続セッションの保存に使用するデータベース表名を指定します。これは
|
jdbc-column-name-max-inactive-interval |
|
|
url-rewriting-enabled |
|
URL書換えを有効にします。これによって、セッションIDがURLにエンコーディングされ、Cookieがブラウザで無効の場合にセッション・トラッキングが実行されます。 |
http-proxy-caching-of-cookies |
|
"Cache-control: no-cache=set-cookie" これは、プロキシ・キャッシュでCookieがキャッシュされないことを示します。 |
encode-session-id-in-query-params |
false |
最新のサーブレットの仕様では、パス・パラメータでセッションIDをエンコードするためにコンテナが必要です。特定のWebサーバーは、パス・パラメータを使用して機能しません。このような場合、 |
runtime-main-attribute |
例: この要素は、さまざまなセッションのセッション実行時情報をタグ付けする場合に役立つ。 |
|
monitoring-attribute-name |
指定されたHTTPセッションの監視IDを構成します。 HTTPセッションは監視IDで識別されます。デフォルトでは、指定されたHTTPセッションの監視IDはランダムな文字列です(セキュリティ上の理由からセッションIDと同じではありません)。この監視IDを構成するには、 この要素は、さまざまなセッションのセッション実行時情報をタグ付けする場合に役立つ。たとえば、一意のusername属性がある場合は、usernameに設定できます。 |
|
cookie-http-only |
|
|
auth-cookie-id-length |
|
セキュアなCookie、 |
この要素は、URLパターン・マッチング用のクラスを指定するために使用します。WebLogic ServerのデフォルトURLマッチ・マッピング・クラスは、Java EE仕様に基づいた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>
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-17 virtual-directory-mapping要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
local-path |
必須 |
ディスク上の物理位置を指定します。 |
url-pattern |
必須 |
マッピングのURLパターンを含みます。Servlet API仕様の11.2項で指定されているルールに準拠している必要があります。 |
仮想ディレクトリ・マッピングのWebLogic Server実装では、マッピングのurl-patternに一致するディレクトリが必要です。上記の画像の例であれば、c:/usr/gifs/images
にimagesというディレクトリを作成する必要があります。これにより、サーブレット・コンテナがimagesディレクトリにある複数のWebアプリケーションの画像を見つけることが可能になります。
weblogic-version
要素は、(ルート要素weblogic-web-app
内に定義されている)当該Webアプリケーションのデプロイ先となるWebLogic Serverのバージョンを示します。この要素は参照用で、現在WebLogic Serverでは使用されていません。
wl-dispatch-policy
要素を使用して、ワーク・マネージャ名を指定し、Webアプリケーションを構成されたワーク・マネージャに割り当てます。このWebアプリケーション・レベルのパラメータは、個々のサーブレットやJSPレベルでディスパッチ・ポリシー設定を使用してオーバーライドできます。ディスパッチ・ポリシーは、次のものを使用して設定できます。
サーブレットのwl-dispatch-policy
(web.xml
の<servlet>
要素の<init-param>
を使用する)
weblogic.xml
の<servlet-descriptor>
要素内にある<dispatch-policy>
要素
注意:
weblogic.xml
の<dispatch-policy>
設定は、web.xml
のwl-dispatch-policy
<init-param>
構成をオーバーライドします。
work-manager
要素はweblogic-web-app
要素の下位要素です。work-manager
要素の内部には以下の要素を定義できます。
表B-18 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つの要素から選択できます。
|
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-compatible
フラグがfalse
に設定されている場合、
バージョン2.1のすべてのJSP/TAGファイルは新しいJSP動作に従います。
バージョン2.0以前のすべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。
Webアプリケーションのバージョンが2.5であり、かつ、backward-compatible
フラグがtrue
に設定されている場合、すべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。
Webアプリケーションのバージョンが2.4以前である場合は、backward-compatible
フラグの設定に関係なく、すべての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-compatible
フラグがtrue
に設定されています。
Webアプリケーションのバージョンが2.4以前です。
バージョン2.5のWebアプリケーションにある個々のJSP/TAGファイルがバージョン2.0以前です。
Webコンテナをグローバル・レベルで構成するには、WebAppContainerMBean
を使用します。WebAppContainerMBean
属性の詳細と、この属性を使用してすべてのWebアプリケーションに対しドメイン全体のデフォルトを指定する方法については、「WebAppContainerMBean」
を参照してください。