Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

weblogic.xml デプロイメント記述子の要素

このマニュアルは、WebLogic Server 固有のデプロイメント記述子 weblogic.xml の要素に関する詳細なリファレンスです。お使いの Web アプリケーションに weblogic.xml デプロイメント記述子が含まれていない場合、WebLogic Server によってこのデプロイメント記述子の要素にデフォルトの値が自動的に選択されます。

以降の節では、weblogic.xml デプロイメント記述子のルート要素 <weblogic-web-app> の下に定義できる複合的なデプロイメント記述子要素について説明します。

 

weblogic.xml のネームスペース宣言とスキーマの場所

WebLogic Server の weblogic.xml ファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。 

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">

weblogic.xml のスキーマについては、http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd を参照してください。

 

description

description 要素は、Web アプリケーションの説明文です。

 

weblogic-version

weblogic-version 要素は、当該 Web アプリケーション (ルート要素 <weblogic-web-app> に定義) のデプロイ先とする WebLogic Server のバージョンを示します。この要素は参照用で、現在 WebLogic Server では使用されていません。

 

security-role-assignment

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 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<role-name>
必須
セキュリティ ロール名を指定する。
<principal-name>
<externally-defined> が定義されていない場合、必須
セキュリティ レルムで定義されるプリンシパルの名前を指定する。複数の <principal-name> 要素を使用してプリンシパルをロールにマップできる。セキュリティ レルムの詳細については、『WebLogic Server のセキュリティ』を参照。
<externally-defined>
<principal-name> が定義されていない場合、必須
特定のセキュリティ ロールがセキュリティ レルムでグローバルに定義されていることを指定する。WebLogic Server では、このセキュリティ ロールをグローバル レルム内でルックアップするのではなくプリンシパル名として使用する。セキュリティ ロールと principal-name のマッピングが別の場所で定義されている場合、これは暗示的なプレースホルダとして使用される。

注意 : security-role-assignment 要素およびその下位要素を定義していない場合は、Web アプリケーション コンテナによってロール名がプリンシパル名として暗黙的にマップされ、ログに警告メッセージが出力されます。マッピングが定義されていないと、EJB コンテナはモジュールをデプロイしません。
注意 : 以下に、ロール名が「role_xyz」の場合の使用例を示します。

 

run-as-role-assignment

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 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<role-name>
必須
セキュリティ ロール名を指定する。
<run-as-principal-name>
必須
プリンシパルの名前を指定する。

 

resource-description

resource-description 要素は、サーバ リソースの JNDI 名を、WebLogic Server の EJB リソースの参照にマップするために使用されます。

次の表では、resource-description 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<res-ref-name>
必須
リソース参照名を指定する。
<jndi-name>
必須
リソースの JNDI 名を指定する。

 

resource-env-description

resource-env-description 要素は、ejb-jar.xml デプロイメント記述子で宣言された resource-env-ref を、それが表しているサーバ リソースの JNDI 名にマップします。

次の表では、resource-env-description 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<res-env-ref-name>
必須
リソース環境参照名を指定する。
<jndi-name>
必須
リソース環境参照の JNDI 名を指定する。

 

ejb-reference-description

次の表では、ejb-reference-description 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<ejb-ref-name>
必須
Web アプリケーションで使用する EJB 参照の名前を指定する。
<jndi-name>
必須
参照の JNDI 名を指定する。

 

service-reference-description

次の表では、service-reference-description 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<service-ref-name>
   
<wsdl-url>
   
<call-property>
 
<call-property> 要素には次の下位要素がある。
  • <name>
  • <value>
<port-info>
 
<port-info> 要素には次の下位要素がある。
  • <port-name>
  • <stub-property>
  • <call-property>

 

session-descriptor

session-descriptor 要素には、サーブレット セッションのパラメータを定義します。

要素名
デフォルト値
値
timeout-secs
3600
WebLogic Server でセッションをタイム アウトするまでに待機する時間を秒単位で指定する。デフォルト値は 3600 秒。
トラフィックの多いサイトでは、セッションのタイムアウトを調整すると、アプリケーションの動作を最適化できる。ブラウザ クライアントでいつでもセッションを終了できるようにする必要がある場合でも、ユーザがサイトを離れるか、ユーザのセッションがタイムアウトになれば、サーバに接続する必要はなくなる。
この属性は、web.xml の session-timeout 要素 (分単位で定義) によってオーバーライドされる可能性がある。
invalidation-interval-secs
60
WebLogic Server が、タイムアウトの無効なセッションに対してハウスクリーニング チェックを実行してから古いセッションを削除してメモリを解放するまでの待ち時間を秒単位で設定する。この要素を使用すると、トラフィックの多いサイトで WebLogic Server の動作を最適化できる。
デフォルト値は 60 秒。
sharing-enabled
false
アプリケーション レベルでこの値を true に設定した場合、複数の Web アプリケーションで HTTP セッションを共有できる。
Web アプリケーション レベルで有効になっている場合、この要素は無視される。
debug-enabled
false
HTTP セッションのデバッグ機能を有効にする。
デフォルト値は false。
id-length
52
セッション ID のサイズを設定する。
最小値は 8 バイト、最大値は Integer.MAX_VALUE で指定した値。
WAP アプリケーションを作成する場合、WAP プロトコルはクッキーをサポートしていないため、URL を書き換える必要がある。また、一部の WAP デバイスでは、URL の長さに 128 文字 (属性も含む) の制限がある。この制限によって、URL 書き換えで転送できるデータ サイズが限られる。属性用の領域を確保するには、WebLogic Server でランダムに生成されるセッション ID のサイズをこの属性で制限する。
WAPEnabled 属性を設定して、長さを 52 文字までに制限し、特殊文字の使用を禁止することもできる。詳細については、『Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「URL 書き換えと Wireless Access Protocol (WAP)」を参照。
tracking-enabled
true
HTTP リクエスト間のセッション トラッキングを有効にする。
cache-size
1028
JDBC とファイル永続セッションのキャッシュ サイズを設定する。
max-in-memory-sessions
-1
メモリ/レプリケートされたセッションの最大セッション数を設定する。
メモリ内で使用できるサーブレット セッションの上限数をコンフィグレーションする機能がない場合、新しいセッションが作成され続けると、最終的にはサーバによってメモリ外への送出が行われる。これを回避するため、WebLogic Server では作成されるセッション数に対して、コンフィグレーション可能な制限を設けている。この数を超えると、新しいセッションの作成が試行されるたびに、weblogic.servlet.SessionCreationException が発生する。この機能は、レプリケートされたインメモリ セッションと、レプリケートされないインメモリ セッションの双方に適用される。
メモリ内で使用できるサーブレット セッションの上限をコンフィグレーションするには、この max-in-memory-sessions 要素に上限値を設定する。
デフォルトは -1 (無制限)。
cookies-enabled
true
セッション クッキーの使用はデフォルトで有効になっているが (推奨)、このプロパティを false に設定して無効にすることも可能。テストのためにこのオプションをオフにする場合もある。
cookie-name
JSESSIONID
セッション トラッキング クッキーの名前を定義する。設定しない場合、デフォルトは JSESSIONID。アプリケーションに対して、より詳細な名前を指定できる。
cookie-path
null
セッション トラッキング クッキーのパスを定義する。
この属性を設定しない場合、デフォルトは / (スラッシュ)。デフォルト値では、ブラウザは、WebLogic Server で指定されているすべての URL にクッキーを送信する。マップ対象を絞り込んだパスを設定し、要求 URL を、ブラウザがクッキーを送信するものに限定できる。
cookie-domain
null
クッキーが有効になるドメインを指定する。たとえば、cookie-domain を .mydomain.com に設定すると、*.mydomain.com ドメイン内のすべてのサーバにクッキーが返される。
ドメイン名には少なくとも 2 つのコンポーネントが必要である。名前を *.com または *.net に設定すると無効になる。
この属性を設定しない場合、デフォルトは、クッキーを発行したサーバのドメイン。
詳細については、Sun Microsystems の Servlet 仕様の Cookie.setDomain() を参照。
cookie-comment
null
クッキー ファイル内のセッション トラッキングを行うクッキーを識別するコメントを指定する。
cookie-secure
false
クッキーを HTTPS 接続でのみ返信するようブラウザに指示する。これにより、クッキー ID が保護され、HTTPS を使用する Web サイトでのみ使用されるようになる。この機能を有効にすると、HTTP でのセッション クッキーは機能しなくなる。
この機能を使用する場合、url-rewriting-enabled 要素は無効にする必要がある。
cookie-max-age-secs
-1
セッション クッキーの有効期間を秒単位で設定する。時間が経過すると、クッキーはクライアントで期限切れになる。
デフォルト値は -1 (無制限)。
クッキーの詳細については、「セッションとセッション永続性の使用」を参照。
persistent-store-type
memory
永続ストレージの方法を次のいずれかに設定する。
  • memory - 永続セッション ストレージを無効にする。
  • replicated - memory と同じだが、セッション データはクラスタ化されたサーバ間でレプリケートされる。
  • replicated_if_clustered - Web アプリケーションがクラスタ化されているサーバにデプロイされている場合は、有効な persistent-store-type がレプリケートされる。それ以外の場合は、memory がデフォルト値。
  • async-replicated - アプリケーションまたは Web アプリケーションで非同期セッション レプリケーションを有効にする。「セッションの永続性のコンフィグレーション」を参照。
  • async-replicated-if-clustered - クラスタ環境にデプロイされる場合、アプリケーションまたは Web アプリケーションで非同期セッション レプリケーションを有効にする。単一のサーバ環境にデプロイされる場合、セッションの永続性/レプリケーションはデフォルトでインメモリになる。これにより、デプロイメント エラーなしで単一サーバでのテストが可能になる。
  • file - ファイル ベースの永続性を使用する (「persistent-store-dir」を参照)。
  • async-jdbc - アプリケーションまたは Web アプリケーションで HTTP セッションの非同期 JDBC 永続性を有効にする。「セッションの永続性のコンフィグレーション」を参照。
  • jdbc - データベースを使用して永続セッションを格納する (「persistent-store-pool」も参照のこと)。
  • cookie - すべてのセッション データはユーザのブラウザ内のクッキーに格納される。
persistent-store-cookie-name
WLCOOKIE
クッキーベースの永続性に使用するクッキーの名前を設定する。WLCOOKIE クッキーはセッション ステートを保持する。このクッキーは Web アプリケーション間で共有されないようにする。
詳細については、「クッキーベースのセッション永続性の使用」を参照。
persistent-store-dir
session_db
ファイルベースの永続化に使用されるストレージ ディレクトリを指定する。
各セッションのサイズに有効なセッション数をかけたサイズを保存できるだけのディスク スペースを確保する必要がある。セッションのサイズは persistent-store-dir に作成されているファイルで確認できる。各セッションのサイズは、シリアライズされたセッション データの変更のサイズによって異なる。
各サーバ インスタンスには、コンフィグレーション不要なデフォルトの永続ファイル ストアがある。したがって、ディレクトリが指定されていない場合は、デフォルトのストアが <server-name>\data\store\default ディレクトリに自動的に作成される。ただし、デフォルトのストアをクラスタ化されたサーバの間で共有することはできない。
複数サーバ間で共有しているディレクトリにカスタム永続ストアを作成すると、ファイル永続セッションをクラスタ対応にできる。ただし、その場合はこのディレクトリを手動で作成する必要がある。
persistent-store-pool
なし
永続ストレージに使用される JDBC 接続プールの名前を指定する。
persistent-store-table
wl_servlet_sessions
JDBC ベースの永続セッションの保存に使用するデータベース テーブル名を指定する。これは persistent-store-type が jdbc に設定されている場合にのみ適用される。
persistent-store-table 要素は、デフォルト以外のデータベース テーブル名を選択した場合にのみ使用される。
jdbc-column-name-max-inactive-interval
 
wl_max_inactive_interval カラム名の代替名として使用される。この jdbc-column-name-max-inactive-interval 要素は JDBC ベースの永続性にのみ適用される。長いカラム名をサポートしていないデータベースでは必須。
jdbc-connection-timeout-secs
120
注意 : この要素はこのリリースでは非推奨。
WebLogic Server が JDBC 接続をタイムアウトするまでの待ち時間を秒単位で設定する (秒数)。
url-rewriting-enabled
true
URL 書き換えを有効にする。これによって、セッション ID が URL にエンコーディングされ、クッキーがブラウザで無効の場合にセッション トラッキングが実行される。
http-proxy-caching-of-cookies
true
false に設定されている場合、応答にはヘッダが以下のように追加される。
“Cache-control: no-cache=set-cookie”
これは、プロキシ キャッシュでクッキーがキャッシュされないことを示す。
encode-session-id-in-query-params
false
最新の Servlet 仕様では、パス パラメータのセッション ID をコンテナでエンコードする必要があるとされているが、Web サーバの中にはパス パラメータを上手く処理できないものもある。このような場合、encode-session-id-in-query-params 要素を true に設定する (デフォルトは false)。
runtime-main-attribute
 
ServletSessionRuntimeMBean で使用される。ServletSessionRuntimeMBean の getMainAttribute() で返されるセッション属性の値で、この要素の文字列がキーとして使われる。
例 : user-name
この要素は、さまざまなセッションのセッション実行時情報をタグ付けする場合に役立つ。

 

jsp-descriptor

jsp-descriptor 要素には、JSP コンパイラのコンフィグレーション パラメータのリストを指定します。次の表で、jsp-descriptor 要素内に定義できる要素について説明します。

要素
デフォルト値
説明
page-check-seconds
1
JSP ファイルが変更されたために再コンパイルする必要があるかどうかをチェックする間隔を秒単位で設定する。変更されている場合は、依存関係もチェックされ、再帰的に再ロードされる。
  • 値 -1 の場合、ページのチェックは行われない。この値は、プロダクション環境でのデフォルト値。
  • 値 0 の場合、ページは常にチェックされる。
  • 値 1 の場合、ページは毎秒チェックされる。この値は、開発環境でのデフォルト値。
JSP を変更することが稀なプロダクション環境では、チューニング要件に応じて、pageCheckSeconds の値を 60 以上に設定することを検討のこと。
precompile
false
true に設定すると、Web アプリケーションのデプロイ (再デプロイ) 時または WebLogic Server の起動時に、変更されたすべての JSP が自動的にあらかじめコンパイルされる。
precompile-continue
false
true に設定すると、いずれかの JSP のコンパイルに失敗しても、変更されたすべての JSP がプリコンパイルされる。precompile が true に設定されている場合にのみ有効。
keepgenerated
false
JSP コンパイル プロセスの間に生成される Java ファイルを保存する。このパラメータを true に設定しない限り、中間生成された Java ファイルはコンパイル後に削除される。
verbose
true
true に設定すると、デバッグ情報がブラウザ、コマンド プロンプト、および WebLogic Server ログ ファイルに出力される。
working-dir
内部に生成されるディレクトリ
WebLogic Server が、JSP 用に生成された Java とコンパイル済みのクラス ファイルを保存するディレクトリの名前。
print-nulls
null
false に設定すると、"null" を含む式は " " として出力される。
backward-compatible
true
true に設定すると、下位互換性が有効になる。
詳細については、「下位互換性フラグ」を参照。
encoding
ユーザのプラットフォームのデフォルト エンコーディング
JSP ページで使用されるデフォルトの文字セットを指定する。標準の Java 文字セット名 (http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html) を使用すること。
この属性を設定しない場合、デフォルトはユーザのプラットフォームのエンコーディング。
JSP コードに含まれる JSP ページ ディレクティブはこの設定をオーバーライドする。次に例を示す。
<%@ page contentType="text/html; charset=custom-encoding”%>
package-prefix
jsp_servlet
すべての JSP ページのコンパイル先となるパッケージのプレフィックスを指定する。
exact-mapping
true
true の場合、JSP の最初の要求時に新しく作成される JspStub が正確な要求にマップされる。exactMapping が false に設定されている場合、Web アプリケーション コンテナは JSP 用に正確ではない url マッピングを生成する。exactMapping は JSP ページのパス情報を提供する。
default-file-name
true
JSP 用の生成済み Java およびコンパイル済みクラス ファイルを保存するファイルのデフォルト名。
rtexprvalue-jsp-param-name
false
jsp:param タグの name 属性に実行時の式の値を指定できるようにする。デフォルトでは false に設定される。
optimize-java-expression
false
true の場合、JSP コンパイラにより Java 式が最適化され実行時のパフォーマンスが改善する。
compress-html-template
false
true の場合、JSP テンプレート ブロック内の HTML が圧縮され実行時のパフォーマンスが改善する。

注意 : JSP の HTML テンプレート ブロックに <pre> HTML タグが含まれる場合は、この機能を有効にしてはならない。

 

auth-filter

auth-filter 要素は、認証フィルタの HttpServlet クラスを指定します。

注意 : この要素は現在のリリースでは非推奨とされています。代わりにサーブレット認証フィルタを使用してください。

 

container-descriptor

<container-descriptor> 要素には、Web アプリケーションの動作に影響するパラメータのリストを指定します。

check-auth-on-forward

<check-auth-on-forward/> 要素は、サーブレットまたは JSP から転送された要求の認証を必要とするときに追加します。再認証を必要としない場合、このタグは省略します。次に例を示します。 

<container-descriptor>
    <check-auth-on-forward/>
</container-descriptor>
注意 : ベスト プラクティスとしては、check-auth-on-forward プロパティを有効にしないことをお勧めします。

filter-dispatched-requests-enabled

<filter-dispatched-requests-enabled> 要素は、ディスパッチされた要求にフィルタを適用するかどうかを制御します。デフォルト値は false です。

注意 : 2.4 サーブレットは、(2.4 仕様に従って) 2.3 サーブレットと下位互換性があるため、2.3 の記述子要素が WebLogic Server で検出された場合、<filter-dispatched-requests-enabled> 要素のデフォルトは true になります。

redirect-with-absolute-url

<redirect-with-absolute-url> 要素は、javax.servlet.http.HttpServletResponse.SendRedirect() メソッドでのリダイレクトに相対 URL と絶対 URL のどちらを使用するかを制御します。プロキシ HTTP サーバを使用しており、URL を非相対リンクに変換したくない場合は、この要素を false に設定します。

デフォルトの動作では、URL が非相対リンクに変換されます。

リダイレクトで使用されるユーザが読めるデータ。

index-directory-enabled

<index-directory-enabled> 要素は、適切なインデックス ファイルが見つからない場合に HTML ディレクトリのリストを自動的に生成するかどうかを制御します。

デフォルト値は false です (ディレクトリは生成されません)。値は true または false です。

index-directory-sort-by

<index-directory-sort-by> 要素は、weblogic.servlet.FileServlet で生成されるディレクトリ リストのソート順序を定義します。有効な sort-by 値は、NAME、LAST_MODIFIED、および SIZE です。デフォルトの sort-by 値は NAME です。

servlet-reload-check-secs

<servlet-reload-check-secs> 要素は、サーブレットが変更されたかどうかを WebLogic Server がチェックして、変更されていた場合に再ロードするかどうかを定義します。

コンソールで指定する値は、手動で設定する値よりも常に優先されます。

resource-reload-check-secs

<resource-reload-check-secs> 要素は、Web アプリケーション スコープのリソース パスで検出されるキャッシュされたリソースのメタデータ キャッシングに使用されます。このパラメータでは、リソースが変更されているかどうかをチェックして変更されていた場合に再ロードを行う頻度を特定します。

このパラメータの値としては Administration Console を使用して指定したものに優先権が与えられます。

single-threaded-servlet-pool-size

<single-threaded-servlet-pool-size> 要素は、SingleThreadMode インスタンス プールで使用するプールのサイズを定義します。デフォルト値は 5 です。

注意 : SingleThreadMode インスタンス プールはこのリリースでは非推奨とされています。

session-monitoring-enabled

<session-monitoring-enabled> 要素を true に設定すると、セッションの実行時 MBean を作成できます。false (デフォルト値) に設定すると、実行時 MBean は作成されません。コンソールで指定する値は、手動で設定する値よりも優先されます。

save-sessions-enabled

<save-sessions-enabled> 要素は、再デプロイまたはアンデプロイ時にセッション データをクリーンアップするかどうかを制御します。これはメモリとレプリケート セッションに影響します。値を true に設定すると、セッション データは保存されます。false に設定すると、Web アプリケーションが再デプロイまたはアンデプロイされるときにセッション データは破棄されます。デフォルトは false です。

prefer-web-inf-classes

<prefer-web-inf-classes> 要素を true に設定すると、Web アプリケーションの WEB-INF ディレクトリ内のクラスが、アプリケーションまたはシステム クラスローダにロードされるクラスよりも優先してロードされます。デフォルト値は false です。コンソールで指定する値は、手動で設定する値よりも優先されます。

default-mime-type

<default-mime-type> 要素のデフォルト値は null です。この要素を使用すると、拡張がマップされていない content-type のデフォルトの MIME タイプを指定できます。

client-cert-proxy-enabled

<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

<relogin-enabled> 要素は下位互換性のためのパラメータです。すでにログインしているユーザが特権を持たないリソースにアクセスしようとすると、応答として FORBIDDEN (403) が発生します。

allow-all-roles

Web アプリケーションの web.xml 記述子に定義されている security-constraints 要素の中では、auth-constraint 要素が、当該リソースの集合へのアクセスを許可する必要があるユーザ ロールを示します。role-name = "*" とすると、Web アプリケーション内のすべてのロールを示す構文を簡単に記述できます。なお、role-name = "*" は以前のリリースでは、レルム内に定義されているすべてのユーザおよびロールを示すものとして扱われていました。

この allow-all-roles 要素は、以前の動作に戻すための下位互換性スイッチです。デフォルトの動作では、Web アプリケーションに定義されているすべてのロールが許可されます。weblogic-xml に指定されている値が、WebAppContainerMBean に定義されている値よりも優先されます。

native-io-enabled

weblogic.servlet.FileServlet (暗黙的に登録されているデフォルトのサーブレット) で静的ファイルを提供しているときにネイティブ I/O を使用するには、native-io-enabled を true に設定します。デフォルト値は false です。native-io-enabled 要素は Windows 上でのみ適用されます。

minimum-native-file-size

minimum-native-file-size 要素は native-io-enabled が true に設定されている場合にのみ適用されます。minimum-native-file-size 要素には、ネイティブ I/O を使用する際の最小ファイル サイズを指定します。提供するファイルのサイズがこの値よりも大きいと、ネイティブ I/O が使用されます。この値を設定しない場合、デフォルト値として 4K が使用されます。

disable-implicit-servlet-mapping

disable-implicit-servlet-mapping フラグが true に設定されている場合、Web アプリケーション コンテナでは内部サーブレット (*.jsp、*.class など) の暗黙的なマッピングが作成されず、デフォルト サーブレットのマッピングのみが作成されます。通常、暗黙的なサーブレット マッピングを無効にするのは、HttpClusterServlet や HttpProxyServlet をコンフィグレーションしている場合です。

デフォルト値は false です。

optimistic-serialization

optimistic-serialization が有効になっている場合、要求がサーブレット コンテキストを超えてディスパッチされるときに getAttribute(name) のコンテキストおよび要求の属性がシリアライズおよびデシリアライズされません。

つまり、複数の Web アプリケーションに共通する属性は、共通の親クラスローダにスコープ指定するか (アプリケーション スコープ指定)、2 つの Web アプリケーションが同じアプリケーションに属していない場合はシステムのクラスパスに配置する必要があります。

optimistic-serialization が無効 (デフォルト値) になっている場合、ClassCastException の発生を回避するために getAttribute(name) のコンテキストおよび要求の属性がシリアライズおよびデシリアライズされます。

optimistic-serialization 値は、WebAppContainerMBean でドメイン レベルで指定することもでき、その場合すべての Web アプリケーションに適用されます。weblogic.xml に値を指定した場合、その値によってドメイン レベルの値がオーバーライドされます。

デフォルト値は false です。

require-admin-traffic

require-admin-trafffic 要素は、トラフィックが管理チャネルを通過する必要があるかどうかを定義します。true に設定すると、トラフィックが管理チャネルを通過できます。true でない場合、トラフィックが管理チャネルを通過できるのは、Web アプリケーションが管理モードにある場合のみです。次に例を示します。 

<container-descriptor>
    <require-admin-traffic>true</require-admin-traffic>
</container-descriptor>

access-logging-disabled

access-logging-disabled 要素は、基底の Web アプリケーションのアクセス ロギングを無効にするかどうかを定義します。このプロパティを true に設定すると、ロギングのオーバーヘッドが小さくなり、サーバのスループットが改善されます。このプロパティを指定しないか false に設定すると、アプリケーションのアクセスがロギングされます。

 

charset-params

<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

<input-charset> 要素を使って、GET データと POST データの読み取りにどの文字セットを使用するのかを定義します。次に例を示します。 

<input-charset>
    <resource-path>/foo</resource-path>
    <java-charset-name>SJIS</java-charset-name>
</input-charset>

詳細については、「HTTP リクエストのエンコーディングの識別」を参照してください。

次の表では、<input-charset> 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<resource-path>
必須
要求の URL に含まれている場合、<java-charset-name> で指定されている Java 文字セットを使用するように WebLogic Server に知らせるパス。
<java-charset-name>
必須
使用する Java 文字セットを指定する。

charset-mapping

<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> 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<iana-charset-name>
必須
<java-charset-name> 要素で指定された Java 文字セットにマップされる IANA 文字セット名を指定する。
<java-charset-name>
必須
使用する Java 文字セットを指定する。

 

virtual-directory-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 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<local-path>
必須
ディスク上の物理位置を指定する。
<url-pattern>
必須
マッピングの URL パターンを含む。Servlet API 仕様のセクション 11.2 で指定されているルールに準拠している必要がある。

仮想ディレクトリ マッピングの WebLogic Server 実装では、マッピングの url-pattern に一致するディレクトリが必要です。上記の画像の例であれば、c:/usr/gifs/images に images というディレクトリを作成する必要があります。これにより、サーブレット コンテナが images ディレクトリにある複数の Web アプリケーションの画像を見つけることが可能になります。

 

url-match-map

この要素は、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

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 はパーミッション クラス名です。

"*" は対象名を示します。

resolve はアクションを示します。

 

context-root

context-root 要素は、このスタンドアロン Web アプリケーションのコンテキスト ルートを定義します。Web アプリケーションがスタンドアロンではなく EAR の一部の場合、EAR の META-INF/application.xml ファイルにコンテキスト ルートを指定します。application.xml の context-root 設定は、weblogic.xml の context-root 設定に優先します。

この weblogic.xml 要素は、2 フェーズ デプロイメント モデルを使用するデプロイメントに対してのみ有効に機能します。

Web アプリケーションのコンテキスト ルートの優先順位は次のとおりです。

  1. application.xml のコンテキスト ルートがチェックされ、見つかった場合はこれが Web アプリケーションのコンテキスト ルートとして使用されます。
  2. コンテキスト ルートの設定が application.xml になく、Web アプリケーションが EAR の一部としてデプロイされる場合、コンテキスト ルートが weblogic.xml に定義されているかどうかがチェックされます。見つかった場合、これが Web アプリケーションのコンテキスト ルートとして使用されます。Web アプリケーションがスタンドアロンとしてデプロイされる場合、application.xml は使用されず、コンテキスト ルートのチェックは weblogic.xml で開始されます。このファイルに定義されていない場合、デフォルトによって URI が使用されます。
  3. コンテキスト ルートが weblogic.xml と application.xml のどちらにも定義されていない場合、コンテキスト パスは URI から推定され、URI に定義されている値から WAR サフィックスを取り除いた名前が付けられます。たとえば、URI が MyWebApp.war の場合は、MyWebApp という名前が付けられます。
注意 : context-root 要素を EAR ライブラリ内の個々の Web アプリケーションに対して設定することはできません。Web アプリケーション ライブラリに対してのみ設定できます。

 

wl-dispatch-policy

wl-dispatch-policy 要素を使用して、ワーク マネージャ名を指定し、Web アプリケーションをコンフィグレーションされたワーク マネージャに割り当てます。この Web アプリケーション レベルのパラメータは、個々のサーブレットや jsp レベルで per-servlet-dispatch-policy 要素を使ってオーバーライドできます。

 

servlet-descriptor

servlet-descriptor 要素を使用して、サーブレット固有の要素を集約します。

次の表では、servlet-descriptor 要素内で定義できる要素について説明します。

要素
必須/省略可能
説明
<servlet-name>
必須
web.xml デプロイメント記述子ファイルのサーブレット要素に定義されたサーブレット名を指定する。
<run-as-principal-name>
省略可能
web.xml デプロイメント記述子に定義された run-as-role-name に対するプリンシパル名を含む。
<init-as-principal-name>
省略可能
サーブレットの init メソッドの run-as-principal-name と同じ。ここに指定する ID はシステムの有効なユーザ名である必要がある。init-as-principal-name を指定しない場合、コンテナは run-as-principal-name 要素を使用する。
<destroy-as-principal-name>
省略可能
サーブレットの destroy メソッドの run-as-principal-name と同じ。ここに指定する ID はシステムの有効なユーザ名である必要がある。destroy-as-principal-name を指定しない場合、コンテナは run-as-principal-name 要素を使用する。
<dispatch-policy>
省略可能
この要素は非推奨。実行キュー名を指定して、コンフィグレーションされた execute-queue に対してある特定のサーブレットを割り当てるために使用する。この設定は、wl-dispatch-policy で定義した Web アプリケーション レベルのディスパッチ ポリシーをオーバーライドする。

 

work-manager

work-manager 要素は <weblogic-web-app> 要素の下位要素です。work-manager 要素の内部には以下の要素を定義できます。

要素
必須/省略可能
説明
name
必須
ワーク マネージャの名前を指定する。
response-time-request-class / fair-share-request-class / context-request-class / request-class-name
省略可能
以下の 4 つの要素から選択できる。
response-time-request-class - アプリケーションの応答時間要求クラスを定義する。応答時間は goal-ms 属性にミリ秒単位で定義する。増分は ((目標値 - T) Cr)/R。T は平均スレッド使用時間、R は到着率、Cr はフェア シェアよりも応答時間目標値を優先させるための係数。
fair-share-request-class - フェア シェア要求クラスを定義する。フェア シェアは、デフォルト シェアに対する属性値の割合で定義される。したがって、デフォルトは 100 になる。増分は Cf/(P R T)。P は割合、R は到着率、T は平均スレッド使用時間、Cf はフェア シェアの優先順位を応答時間目標値よりも低くするための係数。
context-request-class - コンテキスト クラスを定義する。コンテキスト情報 (現在のユーザまたはそのロール、クッキー、作業領域などのフィールド) をサービス クラス名にマッピングした複数のケースを指定して、コンテキストを定義する。
request-class-name - 要求クラス名を定義する。
min-threads-constraint、min-threads-constraint-name
省略可能
以下の 2 つの要素から選択できる。
min-threads-constraint - 制約対象の作業セットの要求に割り当てられるスレッドの数を確保して、デッドロックを回避するために使用する。デフォルトはゼロ。min-threads の値を 1 に設定すると、ピアから同期的に呼び出されるレプリケーション更新要求などの場合に便利。
min-threads-constraint-name - min-threads-constraint 要素の名前を定義する。
max-threads-constraint、max-threads-constraint-name
省略可能
以下の 2 つの要素から選択できる。
max-threads-constraint - 制約対象の作業セットからの要求を実行する同時スレッドの数を制限する。デフォルトは無制限。たとえば、最大スレッド数が 10 に定義された制約を 3 つのエントリ ポイントで共有するとする。このスケジューリング ロジックでは、統合された 3 つのエントリ ポイントからの要求を 10 個以下のスレッドで実行する。
max-threads-constraint-name - max-threads-constraint 要素の名前を定義する。
capacity、capacity-name
省略可能
以下の 2 つの要素から選択できる。
capacity - 制約を定義して、「制約対象の作業セット」と呼ばれるエントリ ポイントのセットに適用できる。この容量に達した場合にのみ、サーバは要求の拒否を開始する。デフォルトはゼロ。容量には、制約対象の作業セットからの全要求 (キューにある要求と実行中の要求) が含まれる。この制約は、独自にフロー制御を行う JMS のようなサブシステムを主な対象としている。この制約は、グローバル キューのしきい値とは無関係。
capacity-name - capacity 要素の名前を定義する。

 

logging

logging 要素は <weblogic-web-app> 要素の下位要素です。logging 要素の内部には以下の要素を定義できます。

要素
必須/省略可能
説明
log-filename
必須

ログ ファイルの名前を指定する。ファイル名は絶対アドレスで指定する必要がある。

logging-enabled
省略可能

ManagedConnectionFactory または ManagedConnection に対してログ ライターが設定されているかどうかを示す。この要素を true に設定すると、ManagedConnectionFactory または ManagedConnection から生成された出力は、log-filename 要素で指定したファイルに送られる。

この値を指定しないと、WebLogic Server では定義されているデフォルト値が使用される。

値の範囲 : true または false。

デフォルト値 : false
rotation-type
省略可能
ファイルのローテーション タイプを設定する。
指定できる値は bySize、byName、none。
  • bySize - ログ ファイルが file-size-limit に指定したサイズに達すると、ファイル名が FileName.n に変更される。
  • byName - file-time-span に指定する時間が経過するたびに、ファイル名が FileName.n に変更される。ファイル名が変更されると、以後のメッセージは log-filename に指定した名前の新しいファイルに蓄積される。
  • none - メッセージは 1 つのファイルに蓄積される。サイズが大きくなった場合、ファイルの内容を消去する必要がある。
デフォルト値 : bySize
number-of-files-limited
省略可能
当該サーバ インスタンスで、古いメッセージの保存用に作成するファイルの数を制限するかどうかを指定する (rotation-type で bySize を指定する必要がある)。この制限に達すると、最も古いファイルが上書きされる。このオプションを有効にしない場合、新しいファイルが無限に作成されていくため、必要に応じてこれらのファイルを削除する必要がある。
number-of-files-limited を true に設定して有効化した場合、ログ ファイルのローテーション方法を判断するために rotationType 変数が参照される。ローテーションでは、新しいファイルを作成するのではなく、既存のファイルが上書きされる。number-of-files-limited を false に設定すると、同じログ ファイルを上書きせずに多数のログ ファイルが作成される。

値の範囲 : true または false。

デフォルト値 : false
file-count
省略可能
サーバがログをローテーションする際に作成するログ ファイルの最大数。この数には、現在のメッセージを格納するためにサーバで使用されているファイルは含まれない (number-of-files-limited を有効にする必要がある)。
デフォルト値 : 7
file-size-limit
省略可能
サーバがログ メッセージを別のファイルに移動するきっかけとなるサイズ (rotation-type で bySize を指定する必要がある)。ログ ファイルが指定の最小サイズに到達すると、以後サーバは、ファイル サイズをチェックする際に、現在のログ ファイルの名前を FileName.n に変更し、それ以降のメッセージを保存するための新規ログ ファイルを作成する。
デフォルト値 : 500
rotate-log-on-startup
省略可能
起動サイクル中にサーバがログ ファイルをローテーションするかどうかを指定する。
値の範囲 : true または false。
デフォルト値 : true
log-file-rotation-dir
省略可能
ローテーションされたログ ファイルが格納されるディレクトリ パスを指定する。
rotation-time
省略可能
ログ ファイルの時間ベースのローテーションの開始時間。フォーマットは k:mm。k は 1 ～ 24。rotation-type で byTime を指定する必要がある。指定された時間に、現在のログ ファイル名が変更される。以後、file-time-span で指定した間隔でログ ファイル名が変更される。
指定した時間がすでに過ぎている場合、サーバは直ちにファイルのローテーションを開始する。
デフォルトでは、ローテーション サイクルは直ちに開始される。
file-time-span
省略可能
古いログ メッセージが別のファイルに移される間隔 (単位は時間)。rotation-type で byTime を指定する必要がある。
デフォルト値 : 24

 

library-ref

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 要素の内部には以下の要素を定義できます。

要素
必須/省略可能
説明
library-name
必須
ライブラリ モジュールの参照用にライブラリの名前を提供する。デフォルト値は null。
specification-version
必須
ライブラリ モジュールの参照用に仕様のバージョンを提供する。デフォルト値は 0 (これは float)。
implementation-version
必須
ライブラリ モジュールの参照用に実装のバージョンを提供する。デフォルト値は null。
exact-match
必須
デフォルト値は false。

 

下位互換性フラグ

WebLogic Server では、WebLogic Server 9.2 以前のリリースに対する下位互換性は jsp-descriptor 要素の backward-compatible 要素を介してサポートされます。Web アプリケーションの下位互換性の詳細については、『WebLogic のアプリケーション環境のアップグレード』の「旧リリースとの互換性」を参照してください。

JSP 2.0 Web アプリケーションとの互換性

JSP 2.1 は WebLogic Server 10.0 からサポートされています。Web アプリケーションのバージョン (バージョン 2.4 または 2.5) と weblogic.xml 記述子ファイルの backward-compatible 要素の設定によっては、JSP 2.0 も Weblogic Server でサポートされます。

JSP の動作とバッファ サフィックス

Servlet 2.5 パッケージの暗黙的なインポート

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 以前の動作に従い、上記の規定されていないパッケージもインポートします。

 

Web コンテナのグローバル コンフィグレーション

Web コンテナをグローバル レベルでコンフィグレーションするには、WebAppContainerMBean を使用します。WebAppContainerMBean 属性の詳細と、この属性を使用してすべての Web アプリケーションに対しドメイン全体のデフォルトを指定する方法については、「WebAppContainerMBean」を参照してください。


ページの先頭       前  次