Apache Tomcat 11 設定リファレンス (11.0.8)

コンテキストコンテナ

はじめに

以下の説明では、ほとんどの相対パスが解決されるベースディレクトリを参照するために変数名 $CATALINA_BASE を使用しています。CATALINA_BASE ディレクトリを設定して Tomcat を複数インスタンスで構成していない場合、$CATALINA_BASE は Tomcat をインストールしたディレクトリである $CATALINA_HOME の値に設定されます。

Context 要素は、特定の仮想ホスト内で実行されるWebアプリケーションを表します。各Webアプリケーションは、サーブレット仕様 (バージョン2.2以降) に記述されているように、Webアプリケーションアーカイブ (WAR) ファイル、または対応する解凍されたコンテンツを含むディレクトリに基づいています。Webアプリケーションアーカイブの詳細については、サーブレット仕様をダウンロードし、Tomcat アプリケーション開発者ガイドを参照してください。

各HTTPリクエストを処理するために使用されるWebアプリケーションは、Catalinaによって、定義された各Contextのコンテキストパスに対してリクエストURIの最長の一致するプレフィックスに基づいて選択されます。選択されると、そのContextは、Webアプリケーションデプロイメントによって定義されたサーブレットマッピングに従って、受信リクエストを処理する適切なサーブレットを選択します。

Context 要素はいくつでも定義できます。各Contextは、仮想ホスト内で一意のコンテキスト名を持つ必要があります。コンテキストパスは一意である必要はありません (以下の並行デプロイを参照)。さらに、コンテキストパスがゼロ長文字列のContextが存在する必要があります。このContextは、この仮想ホストのデフォルトWebアプリケーションとなり、他のContextのコンテキストパスと一致しないすべてのリクエストを処理するために使用されます。

並行デプロイ

同じコンテキストパスを持つWebアプリケーションの複数のバージョンを同時にデプロイできます。リクエストをコンテキストバージョンに一致させるために使用されるルールは次のとおりです

リクエストにセッション情報がない場合は、最新バージョンを使用します。
リクエストにセッション情報がある場合は、各バージョンのセッションマネージャーで一致するセッションをチェックし、見つかった場合はそのバージョンを使用します。
リクエストにセッション情報があるが、一致するセッションが見つからない場合は、最新バージョンを使用します。

Host は、undeployOldVersions を介して、このようにデプロイされた古いバージョンが使用されなくなったときに削除するように設定できます。

命名

HostによってautoDeployまたはdeployOnStartup操作が実行されると、Webアプリケーションの名前とコンテキストパスは、Webアプリケーションを定義するファイルの名前から導出されます。したがって、コンテキストパスはアプリケーションに組み込まれたMETA-INF/context.xmlで定義できない可能性があり、ファイルのコンテキスト名、コンテキストパス、コンテキストバージョン、およびベースファイル名（.warまたは.xml拡張子を除く名前）の間には密接な関係があります。

バージョンが指定されていない場合、コンテキスト名は常にコンテキストパスと同じになります。コンテキストパスが空文字列の場合、ベース名はROOT (常に大文字) となり、それ以外の場合はベース名は先頭の '/' を削除し、残りの '/' 文字を '#' に置き換えたコンテキストパスになります。

バージョンが指定されている場合、コンテキストパスは変更されず、コンテキスト名とベース名の両方に「##」が追加され、その後にバージョン識別子が続きます。

これらの命名規則の例を以下に示します。

コンテキストパス	コンテキストバージョン	コンテキスト名	ベースファイル名	ファイル名の例 (.xml, .war & ディレクトリ)
/foo	なし	/foo	foo	foo.xml, foo.war, foo
/foo/bar	なし	/foo/bar	foo#bar	foo#bar.xml, foo#bar.war, foo#bar
空文字列	なし	空文字列	ROOT	ROOT.xml, ROOT.war, ROOT
/foo	42	/foo##42	foo##42	foo##42.xml, foo##42.war, foo##42
/foo/bar	42	/foo/bar##42	foo#bar##42	foo#bar##42.xml, foo#bar##42.war, foo#bar##42
空文字列	42	##42	ROOT##42	ROOT##42.xml, ROOT##42.war, ROOT##42

バージョンコンポーネントは、パフォーマンス上の理由とバージョン管理スキームの柔軟性を可能にするために、Stringとして扱われます。文字列比較を使用してバージョン順序が決定されます。バージョンが指定されていない場合、空文字列として扱われます。したがって、foo.war は foo##11.war より古いバージョンとして扱われ、foo##11.war は foo##2.war より古いバージョンとして扱われます。純粋な数値バージョン管理スキームを使用する場合は、foo##002.war が foo##011.war より古いバージョンとして扱われるように、ゼロパディングを使用することをお勧めします。

サーブレットで現在のWebアプリケーションのバージョン番号を取得するには、org.apache.catalina.webappVersion 属性を次のように使用します: String webappVersion = (String)request.getServletContext().getAttribute("org.apache.catalina.webappVersion");

ベースファイル名に関連しないコンテキストパスを使用してWARファイルまたはディレクトリをデプロイしたい場合は、二重デプロイメントを防ぐために以下のいずれかのオプションを使用する必要があります

autoDeployとdeployOnStartupを無効にし、すべてのContextをserver.xmlで定義する
WARまたはディレクトリをHostのappBaseの外に配置し、docBase属性を持つcontext.xmlファイルを使用してそれを定義する。

コンテキストの定義

<Context>要素をserver.xmlファイルに直接配置することは推奨されません。これは、メインのconf/server.xmlファイルをTomcatを再起動せずにリロードできないため、Context設定の変更がより侵襲的になるためです。デフォルトのContext要素（下記参照）も、server.xmlに直接配置された<Context>要素の設定を上書きします。これを防ぐには、server.xmlで定義された<Context>要素のoverride属性をtrueに設定する必要があります。

個々のContext要素は明示的に定義できます。

アプリケーションファイル内の/META-INF/context.xmlにある個別のファイル内。オプションで（HostのcopyXML属性に基づき）、これは$CATALINA_BASE/conf/[enginename]/[hostname]/にコピーされ、アプリケーションのベースファイル名に「.xml」拡張子を加えて名前変更される場合があります。
$CATALINA_BASE/conf/[enginename]/[hostname]/ ディレクトリ内の個々のファイル（「.xml」拡張子を持つ）。コンテキストパスとバージョンは、ファイルのベース名（.xml拡張子を除いたファイル名）から導出されます。このファイルは、WebアプリケーションのMETA-INFディレクトリにパッケージ化されたcontext.xmlファイルよりも常に優先されます。
メインのconf/server.xml内のHost要素内。

複数のWebアプリケーションに適用されるデフォルトのContext要素を定義できます。個々のWebアプリケーションの設定は、これらのデフォルトのいずれかで設定されたものを上書きします。デフォルトのContextで定義されたネストされた要素、たとえば<Resource>要素は、デフォルトが適用される各Contextに対して一度作成されます。それらはContext要素間で共有されません。

$CATALINA_BASE/conf/context.xmlファイル内: Context要素情報はすべてのWebアプリケーションによってロードされます。
$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.defaultファイル内: Context要素情報は、そのホストのすべてのWebアプリケーションによってロードされます。

server.xmlを除き、Context要素を定義するファイルは、単一のContext要素のみを定義できます。

明示的に指定されたContext要素に加えて、Context要素を自動的に作成できるいくつかの方法があります。詳細については、自動アプリケーションデプロイおよびユーザーWebアプリケーションを参照してください。

単一のWARファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連しないパスを持つContextを作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。

属性

共通属性

Context のすべての実装は、以下の属性をサポートしています

属性	説明
`allowCasualMultipartParsing`	ターゲットサーブレットが @MultipartConfig アノテーションでマークされていない場合でも、HttpServletRequest.getPart* または HttpServletRequest.getParameter* が呼び出されたときに Tomcat が multipart/form-data リクエストボディを自動的に解析する必要がある場合、`true` に設定します (詳細はサーブレット仕様 3.0、セクション 3.2 を参照)。`false` 以外の設定は、Tomcat が技術的に仕様に準拠しない動作をする原因となることに注意してください。デフォルトは `false` です。
`allowMultipleLeadingForwardSlashInPath`	Tomcat は、URI内の複数の `/` 文字のシーケンスを単一の `/` に正規化します。これは、URIがファイルシステムパスに変換されることが多いため、ファイルシステムの動作との一貫性を保つためです。結果として、`HttpServletRequest#getContextPath()` の戻り値は、一部のURIで複数の `/` 文字で始まることが期待されます。この値が `HttpServletResponse#sendRedirect()` と直接使用される場合、`//` で始まるリダイレクトパスがプロトコル相対リダイレクトとして扱われるため、問題が発生します。潜在的な問題を回避するため、Tomcat は `HttpServletRequest#getContextPath()` の戻り値の先頭にある複数の `/` 文字を単一の `/` に集約します。この属性のデフォルト値は `false` で、これにより複数の `/` 文字の集約が有効になります。この動作を無効にするには、この属性を `true` に設定します。
`altDDName`	このコンテキストの代替デプロイメントディスクリプタへの絶対パス。これは、`/WEB-INF/web.xml` にあるデフォルトのデプロイメントディスクリプタを上書きします。
`alwaysAccessSession`	これが`true`の場合、セッションに関連付けられたすべてのリクエストは、リクエストが明示的にセッションにアクセスするかどうかにかかわらず、セッションの最終アクセス時刻を更新します。 `org.apache.catalina.STRICT_SERVLET_COMPLIANCE`が`true`に設定されている場合、この設定のデフォルトは`true`になり、それ以外の場合はデフォルト値は`false`になります。
`backgroundProcessorDelay`	この値は、このコンテキストとその子コンテナ（すべてのラッパーを含む）でbackgroundProcessメソッドが呼び出されてから次の呼び出しまでの遅延時間を秒単位で表します。子コンテナは、その遅延値が負でない場合（つまり、独自の処理スレッドを使用している場合）は呼び出されません。これを正の値に設定すると、スレッドが生成されます。指定された時間待機した後、スレッドはこのホストとすべての子コンテナでbackgroundProcessメソッドを呼び出します。コンテキストは、セッションの期限切れや再読み込みのためのクラス監視にバックグラウンド処理を使用します。指定されていない場合、この属性のデフォルト値は-1で、これはコンテキストが親ホストのバックグラウンド処理スレッドに依存することを意味します。
`className`	使用する実装のJavaクラス名。このクラスは`org.apache.catalina.Context`インターフェースを実装している必要があります。指定されていない場合、標準値（以下で定義）が使用されます。
`containerSciFilter`	このコンテキストで使用すべきでない、コンテナが提供するSCIをフィルタリングするための正規表現。マッチングには`java.util.regex.Matcher.find()`を使用するため、正規表現はフィルタリングされるコンテナ提供SCIの完全修飾クラス名のサブ文字列に一致するだけでよい。指定されていない場合、フィルタリングは適用されません。
`contextGetResourceRequiresSlash`	これが`true`の場合、`ServletContext.getResource()`または`ServletContext.getResourceAsStream()`に渡されるパスは「/」で始まる必要があります。`false`の場合、Tomcatは提供されたパスに「/」を付加するため、`getResource("myfolder/myresource.txt")`のようなコードが機能します。 `org.apache.catalina.STRICT_SERVLET_COMPLIANCE`が`true`に設定されている場合、この設定のデフォルトは`true`になり、それ以外の場合はデフォルト値は`false`になります。
`cookies`	クライアントがサポートしている場合、セッション識別子の通信にCookieを使用したい場合は`true`に設定します（これがデフォルトです）。セッション識別子の通信にCookieの使用を無効にし、アプリケーションによるURLリライティングのみに依存したい場合は`false`に設定します。
`createUploadTargets`	Servlet の `MultipartConfig` で指定された一時アップロード場所がまだ存在しない場合に、Tomcat がその作成を試みるべきであれば `true` に設定します。指定されていない場合、デフォルト値の `false` が使用されます。
`crossContext`	このアプリケーション内からの`ServletContext.getContext()`の呼び出しが、この仮想ホストで実行されている他のWebアプリケーションに対するリクエストディスパッチャを正常に返すようにしたい場合は`true`に設定します。セキュリティを重視する環境では`false`（デフォルト）に設定し、`getContext()`が常に`null`を返すようにします。
`dispatcherWrapsSameObject`	これが`true`の場合、アプリケーションディスパッチャに渡されるラップされたリクエストまたはレスポンスオブジェクトは、元のリクエストまたはレスポンスをラップしていることを確認するためにチェックされます。 `org.apache.catalina.STRICT_SERVLET_COMPLIANCE`が`true`に設定されている場合、この設定のデフォルトは`true`になり、それ以外の場合はデフォルト値は`false`になります。
`dispatchersUseEncodedPaths`	リクエストディスパッチャを取得するための呼び出しで使用されるパスがエンコードされていると想定されるかどうかを制御します。これは、Tomcatがリクエストディスパッチャを取得するための呼び出しをどのように処理するか、およびTomcatが内部的にリクエストディスパッチャを取得するために使用されるパスをどのように生成するか、の両方に影響します。指定されていない場合、デフォルト値の`true`が使用されます。リクエストディスパッチャのパスをエンコード/デコードする際には、常にUTF-8が使用されます。
`docBase`	このWebアプリケーションのドキュメントベース（コンテキストルートとも呼ばれる）ディレクトリ、またはWebアプリケーションアーカイブファイルへのパス名（このWebアプリケーションがWARファイルから直接実行されている場合）。このディレクトリまたはWARファイルには絶対パス名を指定するか、所有するHostの`appBase`ディレクトリに対する相対パス名を指定できます。このフィールドの値は、Context要素がserver.xmlで定義されているか、`docBase`がHostの`appBase`の下にない限り、設定してはなりません。 `docBase`にシンボリックリンクが使用されている場合、シンボリックリンクへの変更は、Tomcatの再起動後、またはコンテキストをアンデプロイして再デプロイした後にのみ有効になります。コンテキストのリロードだけでは不十分です。
`encodedReverseSolidusHandling`	`reject`に設定すると、`%5c`シーケンスを含むパスの`RequestDispatcher`を取得しようとすると、`IllegalArgumentException`がトリガーされます。`decode`に設定すると、`RequestDispatcher`を取得するために使用されるパス内の`%5c`シーケンスは、`RequestDispatcher`が作成される前に`\`にデコードされ（その後`/`に正規化されます）、変更されません。`passthrough`に設定すると、`RequestDispatcher`を取得するために使用されるパス内の`%5c`シーケンスは変更されません。 `passthrough`が使用される場合、必要な追加の`%nn`デコードを実行するのはアプリケーションの責任です。パス内の`%25`シーケンス（エンコードされた`%`）も、パスが後でアプリケーションによって`%nn`デコードされる際に発生する可能性のある破損やデコード失敗を避けるために、`%25`シーケンスが変更されないまま処理されます。指定されていない場合、デフォルト値は`decode`です。
`encodedSolidusHandling`	`reject`に設定すると、`%2f`シーケンスを含むパスの`RequestDispatcher`を取得しようとすると、`IllegalArgumentException`がトリガーされます。`decode`に設定すると、`RequestDispatcher`を取得するために使用されるパス内の`%2f`シーケンスは、`RequestDispatcher`が作成される前に`/`にデコードされます。`passthrough`に設定すると、`RequestDispatcher`を取得するために使用されるパス内の`%2f`シーケンスは変更されません。 `passthrough`が使用される場合、必要な追加の`%nn`デコードを実行するのはアプリケーションの責任です。パス内の`%25`シーケンス（エンコードされた`%`）も、パスが後でアプリケーションによって`%nn`デコードされる際に発生する可能性のある破損やデコード失敗を避けるために、`%25`シーケンスが変更されないまま処理されます。指定されていない場合、デフォルト値は`decode`です。このデフォルトはTomcat 12で`reject`（Connectorに合わせるため）に変更されます。
`failCtxIfServletStartFails`	load-on-startup >=0 のサーブレットの起動が失敗した場合、コンテキストの起動も失敗させるには `true` に設定します。指定されていない場合、親Host設定で同じ名前の属性が指定されていればそれが使用されます。そうでなければ、デフォルト値の`false`が使用されます。
`fireRequestListenersOnForwards`	Tomcatがリクエストを転送するときに、設定されているServletRequestListenersを発火させるには`true`に設定します。これは主に、リクエストに必要な環境を設定するためにServletRequestListenersを使用するCDIフレームワークのユーザーにとって有用です。指定されていない場合、デフォルト値の`false`が使用されます。
`ignoreAnnotations`	Tomcatがクラスに存在するすべてのアノテーションを無視するようにするには`true`に設定します。指定されていない場合、デフォルト値の`false`が使用されます。
`logEffectiveWebXml`	Webアプリケーションが起動するときに、そのWebアプリケーションで使用される実効web.xmlを（INFOレベルで）ログに出力したい場合は`true`に設定します。実効web.xmlは、アプリケーションのweb.xmlと、Tomcatによって設定されたデフォルト、および検出されたweb-fragment.xmlファイルとアノテーションを結合した結果です。指定されていない場合、デフォルト値の`false`が使用されます。
`mapperContextRootRedirectEnabled`	有効になっている場合、Webアプリケーションのコンテキストルートへのリクエストは、デフォルトのサーブレットではなくマッパーによって必要に応じてリダイレクトされます（末尾にスラッシュを追加します）。これはより効率的ですが、セキュリティ上の副作用があります。第一に、ユーザーがそのディレクトリへのアクセス権を持っていなくても、Webアプリケーションまたはディレクトリの存在が確認される可能性があります。第二に、セキュリティ機能を提供するバルブやフィルタを含む、あらゆるバルブやフィルタはリクエストを処理する機会を得られません。指定されていない場合、デフォルト値の`true`が使用されます。
`mapperDirectoryRedirectEnabled`	有効になっている場合、Webアプリケーションディレクトリへのリクエストは、デフォルトのサーブレットではなくマッパーによって必要に応じてリダイレクトされます（末尾にスラッシュを追加します）。これはより効率的ですが、セキュリティ上の副作用があります。第一に、ユーザーがそのディレクトリへのアクセス権を持っていなくても、Webアプリケーションまたはディレクトリの存在が確認される可能性があります。第二に、セキュリティ機能を提供するバルブやフィルタを含む、あらゆるバルブやフィルタはリクエストを処理する機会を得られません。指定されていない場合、デフォルト値の`false`が使用されます。
`override`	グローバルまたはHostのデフォルトコンテキスト内のすべての設定を無視するには`true`に設定します。デフォルトでは、デフォルトコンテキストからの設定が使用されますが、Contextに対して同じ属性を明示的に設定することで上書きできます。
`parallelAnnotationScanning`	`true`に設定すると、アノテーションスキャンはユーティリティエグゼキュータを使用して実行されます。これにより、スキャンを並行して処理できるため、サーバー負荷が増加する代わりにデプロイメントの種類が改善される可能性があります。指定されていない場合、デフォルトの`false`が使用されます。
`path`	このWebアプリケーションのコンテキストパス。これは、処理のために適切なWebアプリケーションを選択するために、各リクエストURIの先頭と照合されます。特定のHost内のすべてのコンテキストパスは一意でなければなりません。空文字列（""）のコンテキストパスを指定すると、このHostのデフォルトWebアプリケーションを定義することになり、これは他のContextに割り当てられていないすべてのリクエストを処理します。この属性は、server.xmlでContextを静的に定義する場合にのみ使用する必要があります。その他のすべての状況では、パスは.xmlコンテキストファイルまたは`docBase`のいずれかに使用されるファイル名から推測されます。 server.xmlでContextを静的に定義する場合でも、`docBase`がHostの`appBase`の下にない場合、または`deployOnStartup`と`autoDeploy`の両方が`false`である場合を除き、この属性を設定してはなりません。このルールに従わない場合、二重デプロイメントが発生する可能性があります。
`preemptiveAuthentication`	`true`に設定され、セキュリティ制約によって保護されていないリソースに対してユーザーが資格情報を提示した場合、認証器がプリエンプティブ認証をサポートしている（Tomcatに付属の標準認証器はサポートしている）場合、ユーザーの資格情報が処理されます。指定されていない場合、デフォルトの`false`が使用されます。
`privileged`	このコンテキストがマネージャーサーブレットのようなコンテナサーブレットを使用できるようにするには`true`に設定します。`privileged`属性を使用すると、コンテキストの親クラスローダーがSharedクラスローダーではなくServerクラスローダーに変更されます。デフォルトのインストールでは、ServerクラスローダーとSharedクラスローダーの両方にCommonクラスローダーが使用されることに注意してください。
`reloadable`	Catalinaが`/WEB-INF/classes/`および`/WEB-INF/lib`内のクラスの変更を監視し、変更が検出された場合にWebアプリケーションを自動的にリロードするようにしたい場合は`true`に設定します。この機能はアプリケーション開発中に非常に便利ですが、実行時オーバーヘッドが大きく、デプロイ済みの本番アプリケーションでの使用は推奨されません。そのため、この属性のデフォルト設定はfalseです。ただし、デプロイ済みアプリケーションのオンデマンドでのリロードをトリガーするには、Manager Webアプリケーションを使用できます。
`resourceOnlyServlets`	リソースが存在することを期待するサーブレット名（`/WEB-INF/web.xml`で使用される）のコンマ区切りリスト。これにより、リソースが存在しない場合に、リソースが存在することを期待するサーブレット（JSPサーブレットなど）に関連付けられたウェルカムファイルが使用されないようにします。これは、サーブレット3.0仕様のセクション10.10におけるウェルカムファイルマッピングの明確化によって引き起こされる問題を防止します。`org.apache.catalina.STRICT_SERVLET_COMPLIANCE` システムプロパティが`true`に設定されている場合、この属性のデフォルト値は空文字列になり、それ以外の場合は`jsp`になります。
`sendRedirectBody`	`true`の場合、リダイレクト応答には、RFC 2616で推奨されているように、リダイレクトの詳細を含む短い応答ボディが含まれます。応答ボディを含めると、圧縮フィルタなどの一部のアプリケーションコンポーネントに問題を引き起こす可能性があるため、デフォルトでは無効になっています。
`sessionCookieDomain`	このコンテキストのために作成されるすべてのセッションクッキーに使用されるドメイン。設定されている場合、Webアプリケーションによって設定されたすべてのドメインを上書きします。設定されていない場合、Webアプリケーションによって指定された値（もしあれば）が使用されます。
`sessionCookieName`	このコンテキストのために作成されるすべてのセッションクッキーに使用される名前。設定されている場合、Webアプリケーションによって設定されたすべての名前を上書きします。設定されていない場合、Webアプリケーションによって指定された値（もしあれば）が使用されるか、Webアプリケーションが明示的に設定しない場合は`JSESSIONID`が使用されます。
`sessionCookiePath`	このコンテキストのために作成されるすべてのセッションクッキーに使用されるパス。設定されている場合、Webアプリケーションによって設定されたすべてのパスを上書きします。設定されていない場合、Webアプリケーションによって指定された値、またはWebアプリケーションが明示的に設定しない場合は使用されるコンテキストパスが使用されます。すべてのWebアプリケーションが空のパスを使用するように設定するには（これはポートレット仕様の実装に役立ちます）、グローバルな`CATALINA_BASE/conf/context.xml`ファイルでこの属性を`/`に設定します。注: `sessionCookiePath="/"` を使用する1つのWebアプリケーションがセッションを取得すると、同じホスト内で`sessionCookiePath="/"`で構成された他のWebアプリケーションのその後のすべてのセッションは、常に同じセッションIDを使用します。これは、セッションが無効化され、新しいセッションが作成された場合でも適用されます。これにより、セッション固定保護がより困難になり、複数のアプリケーションで共有されるセッションIDを変更するには、Tomcat固有のカスタムコードが必要になります。
`sessionCookiePathUsesTrailingSlash`	Internet Explorer、Safari、Edgeなど一部のブラウザは、RFC6265に違反して、`/foo`のパスを持つコンテキストのセッションクッキーを`/foobar`へのリクエストとともに送信します。これにより、`/foo`にデプロイされたアプリケーションからのセッションIDが`/foobar`にデプロイされたアプリケーションに公開される可能性があります。`/foobar`にデプロイされたアプリケーションが信頼できない場合、これはセキュリティリスクを生じる可能性があります。ただし、RFC 6265のセクション8.5では、パスだけでは信頼できないアプリケーションが他のアプリケーションからクッキーにアクセスするのを防ぐのに十分ではないことが明確にされていることに注意してください。このリスクを軽減するために、この属性を`true`に設定すると、Tomcatはセッションクッキーに関連付けられたパスに末尾のスラッシュを追加し、上記の例ではクッキーパスが/foo/になります。しかし、クッキーパスが/foo/の場合、ブラウザは/fooへのリクエストでクッキーを送信しなくなります。これは、/*にマッピングされたサーブレットがない限り問題にはなりません。この場合、この機能を無効にするには、この属性を`false`に設定する必要があります。この属性のデフォルト値は`false`です。
`suspendWrappedResponseAfterForward`	このフラグの値が`true`の場合、Catalinaはフォワード後にラップされた応答をクローズする代わりに一時停止します。指定されていない場合、このフラグのデフォルト値は`true`です。
`swallowAbortedUploads`	中断されたアップロードに対してTomcatが追加のリクエストボディデータを読み込まず、代わりにクライアント接続を中止する必要がある場合は`false`に設定します。この設定は以下の状況で使用されます。リクエストボディのサイズがコネクタで設定された`maxPostSize`よりも大きい場合 MultiPartアップロードのサイズ制限に達した場合サーブレットが応答ステータスを413（Request Entity Too Large）に設定した場合追加データを読み込まないことで、リクエスト処理スレッドをより迅速に解放できます。残念ながら、ほとんどのHTTPクライアントは、完全なリクエストを書き込めない場合、応答を読み込みません。デフォルトは`true`なので、追加データが読み込まれます。注: リクエスト処理中に5xx応答をトリガーするエラーが発生した場合、未読のリクエストデータは常に無視され、エラー応答が書き込まれるとクライアント接続は閉じられます。
`swallowOutput`	このフラグの値が`true`の場合、WebアプリケーションによってSystem.outおよびSystem.errに出力されるバイトは、Webアプリケーションロガーにリダイレクトされます。指定されていない場合、このフラグのデフォルト値は`false`です。
`tldValidation`	このフラグの値が`true`の場合、コンテキスト起動時にTLDファイルがXML検証されます。`org.apache.catalina.STRICT_SERVLET_COMPLIANCE` システムプロパティが`true`に設定されている場合、この属性のデフォルト値は`true`になり、それ以外の場合はデフォルト値は`false`になります。この属性を`true`に設定すると、パフォーマンス上のペナルティが発生します。
`useHttpOnly`	クライアントサイドスクリプトがセッションIDにアクセスするのを防ぐために、セッションクッキーにHttpOnlyフラグを設定すべきか？デフォルトは`true`です。
`usePartitioned`	セッションクッキーにPartitionedフラグを設定すべきか？デフォルトは`false`です。注: CHIPSの一部としてパーティション化されたクッキーを示すために使用される属性名はRFCによって定義されておらず、同等の機能がRFCに含まれると後方互換性のない方法で変更される可能性があります。
`useRelativeRedirects`	`jakarta.servlet.http.HttpServletResponse#sendRedirect(String)` の呼び出しによって生成される HTTP 1.1 以降のロケーションヘッダーが、相対リダイレクトを使用するか絶対リダイレクトを使用するかを制御します。相対リダイレクトはより効率的ですが、コンテキストパスを変更するリバースプロキシでは機能しない場合があります。複数の問題を引き起こすため、リバースプロキシを使用してコンテキストパスを変更することは推奨されないことに注意してください。絶対リダイレクトは、コンテキストパスを変更するリバースプロキシでは機能しますが、フィルターがスキームやポートを変更している場合、`org.apache.catalina.filters.RemoteIpFilter` で問題を引き起こす可能性があります。`org.apache.catalina.STRICT_SERVLET_COMPLIANCE` システムプロパティが`true`に設定されている場合、この属性のデフォルト値は`false`になり、それ以外の場合はデフォルト値は`true`になります。
`validateClientProvidedNewSessionId`	クライアントが新しいセッションのIDを提供するとき、この属性はそのIDが検証されるかどうかを制御します。クライアントが提供するセッションIDを使用する唯一のユースケースは、複数のWebアプリケーション間で共通のセッションIDを持つことです。したがって、クライアントが提供するセッションIDは、別のWebアプリケーションに既に存在している必要があります。このチェックが有効になっている場合、クライアントが提供するセッションIDは、現在のホストの少なくとも1つの他のWebアプリケーションにセッションIDが存在する場合にのみ使用されます。この設定に関係なく、以下の追加のテストが常に適用されることに注意してください。セッションIDがクッキーによって提供されるセッションクッキーのパスが`/`である指定されていない場合、デフォルト値の`true`が使用されます。
`wrapperClass`	このContextによって管理されるサーブレットに使用される`org.apache.catalina.Wrapper`実装クラスのJavaクラス名。指定されていない場合、標準のデフォルト値が使用されます。
`xmlBlockExternal`	このフラグの値が`true`の場合、このWebアプリケーションの`web.xml`、`web-fragment.xml`、`tomcat-web.xml`、`.tld`、`.jspx`、`*.tagx`、および`tagPlugins.xml`ファイルの解析では、外部エンティティのロードが許可されません。指定されていない場合、デフォルト値の`true`が使用されます。
`xmlNamespaceAware`	このフラグの値が`true`の場合、このWebアプリケーションの`web.xml`、`web-fragment.xml`、および`tomcat-web.xml`ファイルの解析は、名前空間を認識します。`.tld`、`.jspx`、および`*.tagx`ファイルは常に名前空間を認識するパーサーを使用して解析され、`tagPlugins.xml`ファイル（もしあれば）は名前空間を認識するパーサーを使用して解析されないことに注意してください。また、このフラグをオンにする場合、`xmlValidation`もオンにすることをお勧めします。`org.apache.catalina.STRICT_SERVLET_COMPLIANCE` システムプロパティが`true`に設定されている場合、この属性のデフォルト値は`true`になり、それ以外の場合はデフォルト値は`false`になります。この属性を`true`に設定すると、パフォーマンス上のペナルティが発生します。
`xmlValidation`	このフラグの値が`true`の場合、このWebアプリケーションの`web.xml`、`web-fragment.xml`、および`tomcat-web.xml`ファイルの解析は、検証パーサーを使用します。`org.apache.catalina.STRICT_SERVLET_COMPLIANCE` システムプロパティが`true`に設定されている場合、この属性のデフォルト値は`true`になり、それ以外の場合はデフォルト値は`false`になります。この属性を`true`に設定すると、パフォーマンス上のペナルティが発生します。

標準実装

Context の標準実装は org.apache.catalina.core.StandardContext です。これは（上記の共通属性に加えて）以下の追加属性をサポートします。

属性	説明
`addWebinfClassesResources`	この属性は、WebアプリケーションJARファイル内の`META-INF/resources`から静的リソースが提供されるのに加えて、`WEB-INF/classes/META-INF/resources`からも静的リソースが提供されるかどうかを制御します。これは、メジャーバージョンが3以上のWebアプリケーションにのみ適用されます。これはサーブレット3仕様の独自拡張であるため、デフォルトでは無効になっています。この機能を有効にするには、属性を`true`に設定します。
`antiResourceLocking`	`true`の場合、Tomcatはファイルロックをすべて防止します。これによりアプリケーションの起動時間に大きな影響が出ますが、ファイルロックが発生するプラットフォームや構成でWebアプリケーションのホットデプロイおよびアンデプロイを完全に可能にします。指定されていない場合、デフォルト値は`false`です。これを`true`に設定すると、実行中のサーバーでのJSPリロードの無効化など、いくつかの副作用があることに注意してください: Bugzilla 37668を参照してください。このフラグを、Hostの`appBase`（デフォルトでは`webapps`ディレクトリ）の外部にあるアプリケーションで`true`に設定すると、Tomcatシャットダウン時にアプリケーションが削除されることに注意してください。おそらくこれは望ましくないため、Hostの`appBase`の外部にあるWebアプリケーションでantiResourceLocking=trueを設定する前に、よく考えてください。
`clearReferencesHttpClientKeepAliveThread`	`true`の場合、このWebアプリケーションによって`sun.net.www.http.HttpClient`のキープアライブタイマースレッドが開始され、まだ実行中の場合、TomcatはそのスレッドのコンテキストクラスローダーをWebアプリケーションクラスローダーからWebアプリケーションクラスローダーの親に変更し、メモリリークを防ぎます。キープアライブタイマースレッドは、すべてのキープアライブが期限切れになると自動的に停止しますが、ビジーなシステムではしばらく停止しない可能性があります。指定されていない場合、デフォルト値の`true`が使用されます。
`clearReferencesRmiTargets`	`true`の場合、TomcatはRMIターゲットに関連するメモリリークを探し、見つかったものをクリアします。この機能はリフレクションを使用してリークを特定するため、コマンドラインオプション`-XaddExports:java.rmi/sun.rmi.transport=ALL-UNNAMED`が設定されている必要があります。メモリリークのないアプリケーションは、この属性が`false`に設定されていても正しく動作するはずです。指定されていない場合、デフォルト値の`true`が使用されます。
`clearReferencesStopThreads`	`true`の場合、TomcatはWebアプリケーションによって開始されたスレッドを終了しようとします。スレッドの停止は、非推奨（正当な理由で）の`Thread.stop()`メソッドを介して実行され、不安定性をもたらす可能性があります。そのため、これを有効にすることは開発環境における最後の手段として見なされるべきであり、本番環境では推奨されません。指定されていない場合、デフォルト値の`false`が使用されます。この機能が有効になっている場合、Webアプリケーションは停止に最大2秒長くかかる場合があります。これは、実行スレッドに残りのスレッドに対して`Thread.stop()`が呼び出される前に、正常に停止するために最大2秒与えられるためです。
`clearReferencesStopTimerThreads`	`true`の場合、TomcatはWebアプリケーションによって開始された`java.util.Timer`スレッドを終了しようとします。標準のスレッドとは異なり、タイマースレッドは安全に停止できますが、アプリケーションには副作用がある可能性があります。指定されていない場合、デフォルト値の`false`が使用されます。
`clearReferencesThreadLocals`	`true`の場合、TomcatはWebアプリケーションによってロードされたクラスで埋められた`java.lang.ThreadLocal`変数をクリアしようとします。指定されていない場合、デフォルト値の`true`が使用されます。
`copyXML`	アプリケーションに組み込まれたコンテキストXML記述子（`/META-INF/context.xml`に存在する）を、アプリケーションデプロイ時に所有するHostの`xmlBase`にコピーしたい場合は`true`に設定します。それ以降の起動では、アプリケーションに組み込まれたコンテキストXML記述子がより新しい場合でも、コピーされたコンテキストXML記述子が優先して使用されます。デフォルトは`false`です。所有するHostのdeployXML属性が`false`の場合、または所有するHostのcopyXML属性が`true`の場合、この属性は効果がないことに注意してください。
`jndiExceptionOnFailedWrite`	`true`の場合、アプリケーションがbind()、unbind()、createSubContext()、destroySubContext()、またはclose()の呼び出しによって提供されたJNDIコンテキストを変更しようとすると、Jakarta EE仕様のEE.5.3.4項で要求されているように、`javax.naming.OperationNotSupportedException`がトリガーされます。この例外は、この属性を`false`に設定することで無効にできます。その場合、JNDIコンテキストを変更する呼び出しは変更を行わずに戻り、値を返すメソッドは`null`を返します。指定されていない場合、仕様に準拠したデフォルトの`true`が使用されます。
`notFoundClassResourceCacheSize`	標準リソース実装では、クラスリソースは最初にロードされ、その後リソースが不要になるため、キャッシュされません。しかし、いくつかのシナリオでは同じクラスが何度も検索され、JAR/クラスの数が多いほど検索に時間がかかるため、見つからないクラスをキャッシュすることは役立ちます。LRUキャッシュが使用され、この属性はそのキャッシュのサイズを制御します。1未満の値はキャッシュを無効にします。指定されていない場合、デフォルト値の1000が使用されます。
`renewThreadsWhenStoppingContext`	`true`の場合、このコンテキストが停止すると、Tomcatはこのコンテキストを提供するために使用されたスレッドプールからすべてのスレッドを更新します。これはまた、`ThreadLocalLeakPreventionListener`が`server.xml`で設定されており、`Executor`の`threadRenewalDelay`プロパティが>=0であることを必要とします。指定されていない場合、デフォルト値の`true`が使用されます。
`skipMemoryLeakChecksOnJvmShutdown`	`true`の場合、Tomcatは、WebアプリケーションがJVMシャットダウンの一部として停止された場合、Webアプリケーションが停止するときに通常のメモリリークチェックを実行しません。指定されていない場合、デフォルト値の`false`が使用されます。
`unloadDelay`	コンテナがサーブレットのアンロードを待機するミリ秒数。指定されていない場合、デフォルト値は`2000`ミリ秒です。
`unpackWAR`	`false`の場合、所有するHostのunpackWARs属性は上書きされ、WARファイルは解凍されません。`true`の場合、所有するHostのunpackWARs属性の値がWARが解凍されるかどうかを決定します。指定されていない場合、デフォルト値は`true`です。
`useNaming`	このWebアプリケーションに対して、Jakarta EEプラットフォームの慣例と互換性のあるJNDI `InitialContext`をCatalinaが有効にするには、`true`（デフォルト）に設定します。
`workDir`	このContextが提供するスクラッチディレクトリへのパス名で、関連するWebアプリケーション内のサーブレットによる一時的な読み書きに使用されます。このディレクトリは、サーブレット仕様に記述されているように、`jakarta.servlet.context.tempdir`という名前のサーブレットコンテキスト属性（`java.io.File`型）によってWebアプリケーション内のサーブレットに表示されます。指定されていない場合、`$CATALINA_BASE/work`の下の適切なディレクトリが提供されます。

ネストされたコンポーネント

Context 要素内に対応する要素をネストすることにより、以下のユーティリティコンポーネントを最大で1つまでネストできます

Cookie Processor - HTTPクッキーヘッダーの解析と生成を設定します。
Loader - このWebアプリケーションのサーブレットおよびBeanクラスをロードするために使用されるWebアプリケーションクラスローダーを設定します。通常、クラスローダーのデフォルト設定で十分です。
Manager - このWebアプリケーションのHTTPセッションを作成、破棄、および永続化するために使用されるセッションマネージャーを設定します。通常、セッションマネージャーのデフォルト設定で十分です。
Realm - この特定のWebアプリケーション専用に、ユーザーとその関連ロールのデータベースを利用できるようにするレルムを設定します。指定されていない場合、このWebアプリケーションは所有するHostまたはEngineに関連付けられたレルムを使用します。
Resources - このWebアプリケーションに関連付けられた静的リソースにアクセスするために使用されるリソースマネージャーを設定します。通常、リソースマネージャーのデフォルト設定で十分です。
WatchedResource - 自動デプロイヤーは、指定されたWebアプリケーションの静的リソースの更新を監視し、更新された場合にWebアプリケーションをリロードします。この要素の内容は文字列である必要があります。
JarScanner - JARファイルとクラスファイルのディレクトリについてWebアプリケーションをスキャンするために使用されるJarスキャナーを設定します。これは通常、Webアプリケーションの初期化の一部として処理する必要があるTLDやweb-fragment.xmlファイルなどの設定ファイルを識別するために、Webアプリケーションの起動時に使用されます。通常、デフォルトのJarスキャナー設定で十分です。

特別な機能

ロギング

コンテキストは、org.apache.catalina.core.ContainerBase.[enginename].[hostname].[path]ログカテゴリに関連付けられています。角括弧は実際には名前の一部であり、省略しないでください。

アクセスログ

Webサーバーを実行すると、通常生成される出力ファイルの1つにアクセスログがあります。これは、サーバーによって処理された各リクエストについて、標準形式で1行の情報を生成します。Catalinaには、Webサーバーによって作成されたのと同じ標準形式、または任意の数のカスタム形式でアクセスログを作成できる、オプションのValve実装が含まれています。

Catalinaに、Engine、Host、またはContextによって処理されるすべてのリクエストのアクセスログを作成するように依頼するには、次のようにValve要素をネストします

<Context>
  ...
  <Valve className="org.apache.catalina.valves.AccessLogValve"
         prefix="localhost_access_log" suffix=".txt"
         pattern="common"/>
  ...
</Context>

サポートされている設定属性の詳細については、アクセスログバルブを参照してください。

自動コンテキスト設定

標準のContext実装を使用すると、Catalinaが起動したとき、またはこのWebアプリケーションがリロードされるたびに、以下の設定手順が自動的に実行されます。この機能を有効にするために特別な設定は必要ありません。

独自のLoader要素を宣言していない場合、標準のWebアプリケーションクラスローダーが設定されます。
独自のManager要素を宣言していない場合、標準のセッションマネージャーが設定されます。
独自のResources要素を宣言していない場合、標準のリソースマネージャーが設定されます。
conf/web.xmlにリストされているWebアプリケーションプロパティは、このWebアプリケーションのデフォルトとして処理されます。これは、デフォルトのマッピング（*.jsp拡張子を対応するJSPサーブレットにマッピングするなど）や、すべてのWebアプリケーションに適用されるその他の標準機能を確立するために使用されます。
このWebアプリケーションの/WEB-INF/tomcat-web.xmlリソースにリストされているWebアプリケーションプロパティは、（このリソースが存在する場合）処理され、デフォルトよりも優先されます。
このWebアプリケーションの/WEB-INF/web.xmlリソースにリストされているWebアプリケーションプロパティは、（このリソースが存在する場合）処理されます。
Webアプリケーションにユーザー認証が必要となる可能性のあるセキュリティ制約が指定されている場合、選択したログインメソッドを実装する適切なオーセンティケータが設定されます。

コンテキストパラメータ

この要素内に<Parameter>要素をネストすることで、Webアプリケーションにサーブレットコンテキスト初期化パラメータとして表示される名前付き値を設定できます。例えば、次のように初期化パラメータを作成できます。

<Context>
  ...
  <Parameter name="companyName" value="My Company, Incorporated"
         override="false"/>
  ...
</Context>

これは、Webアプリケーションデプロイメントディスクリプタ（/WEB-INF/web.xml）に以下の要素を含めることと等価です。

<context-param>
  <param-name>companyName</param-name>
  <param-value>My Company, Incorporated</param-value>
</context-param>

ただし、この値をカスタマイズするためにデプロイメントディスクリプタの変更は不要です。

<Parameter>要素の有効な属性は以下のとおりです。

属性	説明
`description`	オプション。このコンテキスト初期化パラメータの人間が読める説明。
`name`	作成するコンテキスト初期化パラメータの名前。
`override`	Webアプリケーションデプロイメントディスクリプタで見つかった同じパラメータ名に対する`<context-param>`が、ここで指定された値を上書きするのを望まない場合は、これを`false`に設定します。デフォルトでは、上書きが許可されています。
`value`	`ServletContext.getInitParameter()`を呼び出してアプリケーションから要求されたときにアプリケーションに提示されるパラメータ値。

環境エントリ

この要素内に<Environment>エントリをネストすることで、環境エントリリソースとしてWebアプリケーションに表示される名前付き値を設定できます。例えば、次のように環境エントリを作成できます。

<Context>
  ...
  <Environment name="maxExemptions" value="10"
         type="java.lang.Integer" override="false"/>
  ...
</Context>

これは、Webアプリケーションデプロイメントディスクリプタ（/WEB-INF/web.xml）に以下の要素を含めることと等価です。

<env-entry>
  <env-entry-name>maxExemptions</env-entry-name>
  <env-entry-value>10</env-entry-value>
  <env-entry-type>java.lang.Integer</env-entry-type>
</env-entry>

ただし、この値をカスタマイズするためにデプロイメントディスクリプタの変更は不要です。

<Environment>要素の有効な属性は以下のとおりです。

属性	説明
`description`	オプション。この環境エントリの人間が読める説明。
`name`	`java:comp/env`コンテキストに相対的に作成する環境エントリの名前。
`override`	Webアプリケーションデプロイメントディスクリプタで見つかった同じ環境エントリ名に対する`<env-entry>`が、ここで指定された値を上書きするのを望まない場合は、これを`false`に設定します。デフォルトでは、上書きが許可されています。
`type`	この環境エントリについて、Webアプリケーションが期待する完全修飾Javaクラス名。Webアプリケーションデプロイメントディスクリプタの`<env-entry-type>`に対する有効な値でなければなりません。
`value`	JNDIコンテキストから要求されたときにアプリケーションに提示されるパラメータ値。この値は、`type`属性で定義されたJava型に変換可能でなければなりません。

ライフサイクルリスナー

このContextが開始または停止されるタイミングを知る必要があるJavaオブジェクトを実装している場合、この要素内にListener要素をネストすることでそれを宣言できます。指定するクラス名はorg.apache.catalina.LifecycleListenerインターフェースを実装している必要があり、クラスはjarにパッケージ化され、$CATALINA_HOME/libディレクトリに配置されている必要があります。対応するライフサイクルイベントの発生について通知されます。このようなリスナーの設定は次のようになります。

<Context>
  ...
  <Listener className="com.mycompany.mypackage.MyListener" ... >
  ...
</Context>

リスナーは、この要素から設定できる任意の数の追加プロパティを持つことができることに注意してください。属性名は、標準のプロパティメソッド命名パターンを使用して、対応するJavaBeanプロパティ名と照合されます。

リクエストフィルタ

Catalinaに、囲んでいるEngine、Host、またはContext要素に向けられたすべての受信リクエストについて、IPアドレスまたはホスト名をチェックするように依頼できます。リモートアドレスまたは名前は、java.util.regex正規表現構文を使用して定義された「許可」および/または「拒否」フィルタと照合されます。許可されていない場所からのリクエストは、HTTP「Forbidden」エラーで拒否されます。フィルタ宣言の例：

<Context>
  ...
  <Valve className="org.apache.catalina.valves.RemoteHostValve"
         allow=".*\.mycompany\.com|www\.yourcompany\.com"/>
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         deny="192\.168\.1\.\d+"/>
  ...
</Context>

サポートされている設定オプションの詳細については、リモートアドレスフィルタとリモートホストフィルタを参照してください。

リソース定義

Webアプリケーションデプロイメントディスクリプタの<resource-ref>および<resource-env-ref>要素のJNDIルックアップによって返されるリソースの特性を宣言できます。使用するオブジェクトファクトリ（Tomcatにまだ知られていない場合）と、そのオブジェクトファクトリを設定するために使用されるプロパティを設定するために、必要なリソースパラメータをResource要素の属性として定義する必要があります。

例えば、次のようにリソース定義を作成できます。

<Context>
  ...
  <Resource name="jdbc/EmployeeDB" auth="Container"
            type="javax.sql.DataSource"
     description="Employees Database for HR Applications"/>
  ...
</Context>

これは、Webアプリケーションデプロイメントディスクリプタ（/WEB-INF/web.xml）に以下の要素を含めることと等価です。

<resource-ref>
  <description>Employees Database for HR Applications</description>
  <res-ref-name>jdbc/EmployeeDB</res-ref-name>
  <res-ref-type>javax.sql.DataSource</res-ref-type>
  <res-auth>Container</res-auth>
</resource-ref>

ただし、この値をカスタマイズするためにデプロイメントディスクリプタの変更は不要です。

<Resource>要素の有効な属性は以下のとおりです。

属性	説明
`auth`	Webアプリケーションコードが対応するリソースマネージャーにプログラムでサインオンするか、またはコンテナがアプリケーションに代わってリソースマネージャーにサインオンするかを指定します。この属性の値は`Application`または`Container`である必要があります。WebアプリケーションがWebアプリケーションデプロイメント記述子で`<resource-ref>`要素を使用する場合、この属性は必須ですが、アプリケーションが代わりに`<resource-env-ref>`を使用する場合はオプションです。
`closeMethod`	シングルトンリソースが不要になったときに呼び出す引数なしメソッドの名前。これは、ガベージコレクションの一部として行われるはずのリソースのクリーンアップを高速化することを目的としています。`singleton`属性が`false`の場合、この属性は無視されます。 Apache Commons DBCP 2 やデフォルトのApache Tomcatコネクションプールなど、`AutoCloseable`を実装する`javax.sql.DataSource`および`javax.sql.XADataSource`リソースの場合、この属性のデフォルトは`close`です。この属性を空文字列に設定することで無効にできます。他のすべてのリソースタイプではデフォルトは定義されておらず、デフォルトではクローズメソッドは呼び出されません。
`description`	オプション。このリソースの人間が読める説明。
`name`	`java:comp/env`コンテキストに相対的に作成するリソースの名前。
`scope`	このリソースマネージャーを介して取得した接続を共有できるかどうかを指定します。この属性の値は`Shareable`または`Unshareable`である必要があります。デフォルトでは、接続は共有可能であると見なされます。
`singleton`	このリソース定義がシングルトンリソース（すなわち、リソースの単一インスタンスのみが存在するリソース）であるかどうかを指定します。この属性が`true`の場合、このリソースに対する複数のJNDIルックアップは同じオブジェクトを返します。この属性が`false`の場合、このリソースに対する複数のJNDIルックアップは異なるオブジェクトを返します。`javax.sql.DataSource`リソースでは、DataSourceのJMX登録を有効にするために、この属性は`true`である必要があります。この属性の値は`true`または`false`である必要があります。デフォルトでは、この属性は`true`です。
`type`	Webアプリケーションがこのリソースのルックアップを実行するときに期待する完全修飾Javaクラス名。

リソースリンク

この要素は、グローバルJNDIリソースへのリンクを作成するために使用されます。リンク名でJNDIルックアップを実行すると、リンクされたグローバルリソースが返されます。

例えば、次のようにリソースリンクを作成できます。

<Context>
  ...
  <ResourceLink name="linkToGlobalResource"
            global="simpleValue"
            type="java.lang.Integer"
  ...
</Context>

<ResourceLink>要素の有効な属性は以下のとおりです。

属性	説明
`global`	グローバルJNDIコンテキスト内のリンクされたグローバルリソースの名前。
`name`	`java:comp/env`コンテキストに相対的に作成するリソースリンクの名前。
`type`	Webアプリケーションがこのリソースリンクのルックアップを実行するときに期待する完全修飾Javaクラス名。
`factory`	これらのオブジェクトを作成するクラスの完全修飾Javaクラス名。このクラスは`javax.naming.spi.ObjectFactory`インターフェースを実装する必要があります。

属性factory="org.apache.naming.factory.DataSourceLinkFactory"が指定された場合、リソースリンクは2つの追加属性とともに使用され、共有データソースを異なる資格情報で使用できます。これらの2つの追加属性がjavax.sql.DataSource型と組み合わせて使用される場合、異なるコンテキストが異なる資格情報でグローバルデータソースを共有できます。内部的には、getConnection()への呼び出しは、単にグローバルデータソースに対するgetConnection(username, password)への呼び出しに変換されます。これは、どのスキーマが使用されているかに対してコードを透過的に保ちながら、グローバル設定で接続（またはプール）を制御できる簡単な方法です。

属性	説明
`username`	リンクされたグローバルDataSourceへの`getConnection(username, password)`呼び出しのための`username`値。
`password`	リンクされたグローバルDataSourceへの`getConnection(username, password)`呼び出しのための`password`値。

共有データソースの例

警告: この機能は、グローバルDataSourceがgetConnection(username, password)メソッドをサポートしている場合にのみ機能します。Tomcatがデフォルトで使用するApache Commons DBCP 2プールはこれをサポートしていません。BasicDataSourceクラスのJavadocを参照してください。Apache Tomcat JDBCプールはこれをサポートしていますが、デフォルトではこのサポートは無効になっており、alternateUsernameAllowed属性によって有効にできます。詳細はそのドキュメントを参照してください。

<GlobalNamingResources>
  ...
  <Resource name="sharedDataSource"
            global="sharedDataSource"
            type="javax.sql.DataSource"
            factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
            alternateUsernameAllowed="true"
            username="bar"
            password="barpass"
            ...
  ...
</GlobalNamingResources>

<Context path="/foo"...>
  ...
  <ResourceLink
            name="appDataSource"
            global="sharedDataSource"
            type="javax.sql.DataSource"
            factory="org.apache.naming.factory.DataSourceLinkFactory"
            username="foo"
            password="foopass"
  ...
</Context>
<Context path="/bar"...>
  ...
  <ResourceLink
            name="appDataSource"
            global="sharedDataSource"
            type="javax.sql.DataSource"
  ...
</Context>

/fooコンテキストでgetConnection()のリクエストが行われると、そのリクエストはgetConnection("foo","foopass")に変換されます。一方、/barでのリクエストはそのまま渡されます。

トランザクション

java:comp/UserTransactionのJNDIルックアップによって返されるUserTransactionの特性を宣言できます。このオブジェクトをインスタンス化するためのオブジェクトファクトリクラス、および必要なリソースパラメータをTransaction要素の属性として、さらにそのオブジェクトファクトリを設定するために使用されるプロパティを定義する必要があります。

<Transaction>要素の有効な属性は以下のとおりです。

属性	説明
`factory`	JNDIオブジェクトファクトリのクラス名。

コンテキストコンテナ

目次

はじめに

並行デプロイ

命名

コンテキストの定義

属性

共通属性

標準実装

ネストされたコンポーネント

特別な機能

ロギング

アクセスログ

自動コンテキスト設定

コンテキストパラメータ

環境エントリ

ライフサイクルリスナー

リクエストフィルタ

リソース定義

リソースリンク

トランザクション