|
このマニュアルは、WebLogic Server 固有のデプロイメント記述子 weblogic.xml の要素に関する詳細なリファレンスです。お使いの Web アプリケーションに weblogic.xml デプロイメント記述子が含まれていない場合、WebLogic Server によってこのデプロイメント記述子の要素にデフォルトの値が自動的に選択されます。weblogic.xml
のスキーマについては、http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd を参照してください。
以降の節では、weblogic.xml デプロイメント記述子のルート要素 <weblogic-web-app>
の下に定義できる複合的なデプロイメント記述子要素について説明します。
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
要素内で定義できる要素について説明します。
<principal-name> 要素を使用してプリンシパルをロールにマップできる。セキュリティ レルムの詳細については、『WebLogic Server のセキュリティ』を参照。
|
||
注意 : | security-role-assignment 要素およびその下位要素を定義していない場合は、Web アプリケーション コンテナによってロール名がプリンシパル名として暗黙的にマップされ、ログに警告メッセージが出力されます。マッピングが定義されていないと、EJB コンテナはモジュールをデプロイしません。 |
注意 : | 以下に、ロール名が「role_xyz」の場合の使用例を示します。 |
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
要素には、サーブレット セッションのパラメータを定義します。
注意 : | セッション コンテキストを初期化する場合、weblogic-application.xml のほとんどのセッション デプロイメント記述子は、weblogic.xml よりも優先されます。未定義のプロパティがある場合は、それが weblogic.xml に存在している場合でもデフォルト値が使用されます。ただし、両方の XML ファイルが使用されている場合、次のプロパティについては weblogic.xml が優先されます。 |
debug-enabled
cache-size
cookie-max-age-secs
timeout-secs
max-in-memory-sessions
monitoring-attribute-name
invalidation-interval-secs
|
||
|
||
|
||
|
||
persistent-store-dir に作成されているファイルで確認できる。各セッションのサイズは、シリアライズされたセッション データの変更のサイズによって異なる。
|
||
jsp-descriptor
要素には、JSP コンパイラのコンフィグレーション パラメータのリストを指定します。次の表で、jsp-descriptor
要素内に定義できる要素について説明します。
|
||
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 がチェックして、変更されていた場合に再ロードするかどうかを定義します。
コンソールで指定する値は、手動で設定する値よりも常に優先されます。
<resource-reload-check-secs> 要素は、Web アプリケーション スコープのリソース パスで検出されるキャッシュされたリソースのメタデータ キャッシングに使用されます。このパラメータでは、リソースが変更されているかどうかをチェックして変更されていた場合にリロードを行う頻度を特定します。
このパラメータの値としては 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 に設定されている場合にのみ適用されます。minimum-native-file-size 要素には、ネイティブ I/O を使用する際の最小ファイル サイズを指定します。提供するファイルのサイズがこの値よりも大きいと、ネイティブ I/O が使用されます。この値を設定しない場合、デフォルト値として 4K が使用されます。
disable-implicit-servlet-mapping フラグが true に設定されている場合、Web アプリケーション コンテナでは内部サーブレット (*.jsp、*.class など) の暗黙的なマッピングが作成されず、デフォルト サーブレットのマッピングのみが作成されます。通常、暗黙的なサーブレット マッピングを無効にするのは、HttpClusterServlet や HttpProxyServlet をコンフィグレーションしている場合です。
optimistic-serialization が有効になっている場合、リクエストがサーブレット コンテキストを超えてディスパッチされるときに getAttribute(name) のコンテキストとリクエスト属性がシリアライズおよびデシリアライズされません。
つまり、複数の Web アプリケーションに共通する属性は、共通の親クラスローダにスコープ指定するか (アプリケーション スコープ指定)、2 つの Web アプリケーションが同じアプリケーションに属していない場合はシステムのクラスパスに配置する必要があります。
optimistic-serialization が無効 (デフォルト値) になっている場合、ClassCastException の発生を回避するために getAttribute(name) のコンテキストおよびリクエストの属性がシリアライズおよびデシリアライズされます。
optimistic-serialization 値は、WebAppContainerMBean でドメイン レベルで指定することもでき、その場合すべての Web アプリケーションに適用されます。weblogic.xml に値を指定した場合、その値によってドメイン レベルの値がオーバーライドされます。
WebAppComponentRuntimeBean.getSessionIds()
メソッドを呼び出すと、この名前を持つセッション属性値の配列が返されます。設定されていない場合、ランダムに生成された String 値の配列が返されます。
require-admin-trafffic
要素は、トラフィックが管理チャネルを経由するかどうかを定義します。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 要素内で定義できる要素について説明します。
仮想ディレクトリ マッピングの 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 のルールを示します。
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>
permission java.net.SocketPermission はパーミッション クラス名です。
context-root 要素は、このスタンドアロン Web アプリケーションのコンテキスト ルートを定義します。Web アプリケーションがスタンドアロンではなく EAR の一部の場合、EAR の META-INF/application.xml ファイルにコンテキスト ルートを指定します。application.xml の context-root 設定は、weblogic.xml の context-root 設定に優先します。
この weblogic.xml 要素は、2 フェーズ デプロイメント モデルを使用するデプロイメントに対してのみ有効に機能します。
Web アプリケーションのコンテキスト ルートの優先順位は次のとおりです。
注意 : | context-root 要素を EAR ライブラリ内の個々の Web アプリケーションに対して設定することはできません。Web アプリケーション ライブラリに対してのみ設定できます。 |
wl-dispatch-policy 要素を使用して、実行キュー名を指定し、Web アプリケーションをコンフィグレーションされた実行キューに割り当てます。この Web アプリケーション レベルのパラメータは、個々のサーブレットや jsp レベルで per-servlet-dispatch-policy 要素を使ってオーバーライドできます。
servlet-descriptor 要素を使用して、サーブレット固有の要素を集約します。
次の表では、servlet-descriptor 要素内で定義できる要素について説明します。
work-manager
要素は <weblogic-web-app>
要素の下位要素です。work-manager
要素の内部には以下の要素を定義できます。
logging
要素は <weblogic-web-app>
要素の下位要素です。logging
要素の内部には以下の要素を定義できます。
library-ref 要素では、現在の Web アプリケーションの Web アプリケーション ライブラリとして使用されるライブラリ モジュールを参照します。
<library-ref>
WebAppLibraryFoo
<library-name></library-name>
<exact-match>false</exact-match>
<specification-version>2.0</specification-version>
<implementation-version>8.1beta</implementation-version>
</library-ref>
Web アプリケーションに関連する下位要素は library-name
、specification-version
、implementation-version
、および exact-match のみです。
library-ref
要素の内部には以下の要素を定義できます。
WebLogic Server 9.0 よりも前のリリースの動作に戻せるように、複数の下位互換性フラグが追加されています。これらのフラグの詳細なリストや説明、また Web アプリケーション、JSP、およびサーブレットの下位互換性については、『WebLogic のアプリケーション環境のアップグレード』の「旧リリースとの互換性」を参照してください。
Web コンテナをグローバル レベルでコンフィグレーションするには、WebAppContainerMBean を使用します。WebAppContainerMBean の属性と、それを使用してすべての Web アプリケーションに対しドメイン全体のデフォルトを指定する方法については、http://edocs.beasys.co.jp/e-docs/wls/docs92/wlsmbeanref/mbeans/WebAppContainerMBean.html で WebAppContainerMBean を参照してください。