Apache Tomcat 10 構成リファレンス (10.1.23)

Context コンテナ

はじめに

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

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

各 HTTP リクエストを処理するために使用される Web アプリケーションは、定義された各 Context のコンテキストパスに対してリクエスト URI の最長の可能なプレフィックスを一致させることに基づいて、Catalina によって選択されます。一度選択されると、その 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.xml, foo#bar.war, foo#bar
空の文字列	なし	空の文字列	なし	ROOT.xml, ROOT.war, ROOT
/foo	42	/foo##42	42	foo##42
/foo/bar	42	foo##42.xml、foo##42.war、foo##42	/foo/bar##42	42
空の文字列	42	##42	foo#bar##42	foo#bar##42.xml、foo#bar##42.war、foo#bar##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 より前のバージョンとして扱われるようにゼロパディングを使用することをお勧めします。
ベースファイル名に関連付けられていないコンテキストパスを使用して 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`	Tomcatは、URI内の複数の`/`文字の並びを単一の`/`に正規化します。これは、URIがファイルシステムのパスに変換されることが多いため、ファイルシステムの動作との一貫性を保つためです。結果として、一部のURIでは、`HttpServletRequest#getContextPath()`の戻り値が複数の`/`文字で始まることが予想されます。この値を`HttpServletResponse#sendRedirect()`で直接使用すると、`//`で始まるリダイレクトパスはプロトコル相対リダイレクトとして扱われるため、問題が発生します。潜在的な問題を回避するために、Tomcatは`HttpServletRequest#getContextPath()`の戻り値の先頭にある複数の`/`文字を単一の`/`にまとめます。この属性のデフォルト値は`false`で、複数の`/`文字のまとめを有効にします。この動作を無効にするには、この属性を`true`に設定してください。
`altDDName`	このコンテキストの代替デプロイメント記述子への絶対パス。これは、`/WEB-INF/web.xml`にあるデフォルトのデプロイメント記述子をオーバーライドします。
`alwaysAccessSession`	これが`true`の場合、セッションに関連付けられたすべてのリクエストは、リクエストが明示的にセッションにアクセスするかどうかに関わらず、セッションの最終アクセス時刻が更新されます。 `org.apache.catalina.STRICT_SERVLET_COMPLIANCE`が`true`に設定されている場合、この設定のデフォルトは`true`になり、そうでない場合はデフォルト値は`false`になります。
`backgroundProcessorDelay`	この値は、このコンテキストとその子コンテナ（すべてのラッパーを含む）でバックグラウンド処理メソッドの呼び出しの間隔を秒単位で表します。子コンテナの遅延値が負でない場合（つまり、独自の処理スレッドを使用している場合）、子コンテナは呼び出されません。これを正の値に設定すると、スレッドが生成されます。指定された時間待機した後、スレッドはこのホストとすべての子コンテナでバックグラウンド処理メソッドを呼び出します。コンテキストは、セッションの有効期限切れや再読み込みのためのクラス監視を実行するためにバックグラウンド処理を使用します。指定しない場合、この属性のデフォルト値は-1です。これは、コンテキストが親ホストのバックグラウンド処理スレッドに依存することを意味します。
`className`	使用する実装のJavaクラス名。このクラスは`org.apache.catalina.Context`インターフェースを実装する必要があります。指定しない場合は、標準値（下記参照）が使用されます。
`containerSciFilter`	このコンテキストで使用すべきでない、コンテナが提供するSCIをフィルタリングするために使用する正規表現を指定します。マッチングは`java.util.regex.Matcher.find()`を使用するため、正規表現は、フィルタリング対象となるコンテナ提供のSCIの完全修飾クラス名の一部分に一致する必要があります。指定しない場合、フィルタリングは適用されません。
`contextGetResourceRequiresSlash`	これが`true`の場合、`ServletContext.getResource()`または`ServletContext.getResourceAsStream()`に渡されるパスは"/"で始まる必要があります。`false`の場合、`getResource("myfolder/myresource.txt")`のようなコードは、Tomcatが提供されたパスの先頭に"/"を付加するため、機能します。 `org.apache.catalina.STRICT_SERVLET_COMPLIANCE`が`true`に設定されている場合、この設定のデフォルトは`true`になり、そうでない場合はデフォルト値は`false`になります。
`cookies`	クライアントがサポートしている場合、セッション識別子通信にクッキーを使用したい場合は、`true`に設定します（これがデフォルトです）。セッション識別子通信にクッキーの使用を無効にし、アプリケーションによるURL書き換えのみに依存したい場合は、`false`に設定します。
`createUploadTargets`	TomcatがServletの`MultipartConfig`で指定された一時的なアップロード場所が存在しない場合に、作成を試みる必要がある場合は`true`に設定します。指定しない場合、デフォルト値の`false`が使用されます。
`crossContext`	このアプリケーション内の`ServletContext.getContext()`への呼び出しが、この仮想ホスト上で実行されている他のWebアプリケーションのリクエストディスパッチャーを正常に返すようにしたい場合は、`true`に設定します。セキュリティを重視する環境で、`getContext()`が常に`null`を返すようにするには、`false`（デフォルト）に設定します。
`dispatcherWrapsSameObject`	これが`true`の場合、アプリケーションディスパッチャーに渡されるラップされたリクエストまたはレスポンスオブジェクトは、元のリクエストまたはレスポンスをラップしていることを確認するためにチェックされます。 `org.apache.catalina.STRICT_SERVLET_COMPLIANCE`が`true`に設定されている場合、この設定のデフォルトは`true`になり、そうでない場合はデフォルト値は`false`になります。
`docBase`	このWebアプリケーションのドキュメントベース（コンテキストルートとも呼ばれる）ディレクトリ、またはWebアプリケーションアーカイブファイルへのパス名（このWebアプリケーションがWARファイルから直接実行されている場合）。このディレクトリまたはWARファイルへの絶対パス名、または所有するHostの`appBase`ディレクトリに対する相対パス名を指定できます。このフィールドの値は、Context要素がserver.xmlで定義されているか、`docBase`がHostの`appBase`の下にない場合を除き、設定しないでください。シンボリックリンクが`docBase`に使用されている場合、シンボリックリンクへの変更はTomcatの再起動後、またはコンテキストのアンデプロイと再デプロイによってのみ有効になります。コンテキストのリロードでは不十分です。
`dispatchersUseEncodedPaths`	リクエストディスパッチャーを取得するための呼び出しで使用されるパスがエンコードされていることを期待するかどうかを制御します。これは、Tomcatがリクエストディスパッチャーを取得するための呼び出しを処理する方法と、Tomcatが内部でリクエストディスパッチャーを取得するために使用するパスを生成する方法の両方に影響します。指定しない場合、デフォルト値の`true`が使用されます。リクエストディスパッチャーのパスをエンコード/デコードするときは、常にUTF-8が使用されます。
`failCtxIfServletStartFails`	起動時に読み込み>=0のサーブレットの起動が失敗した場合に、コンテキストの起動を失敗させるには、`true`に設定します。指定しない場合、親のHost構成内の同じ名前の属性が指定されていれば使用されます。それ以外の場合は、デフォルト値の`false`が使用されます。
`fireRequestListenersOnForwards`	Tomcatがリクエストを転送するときに、構成されたServletRequestListenersを起動するには、`true`に設定します。これは主に、ServletRequestListenersを使用してリクエストに必要な環境を構成するCDIフレームワークのユーザーにとって役立ちます。指定しない場合、デフォルト値の`false`が使用されます。
`logEffectiveWebXml`	アプリケーションの起動時に、Webアプリケーションに使用される有効なweb.xmlを（INFOレベルで）ログに記録したい場合は、`true`に設定します。有効なweb.xmlは、アプリケーションのweb.xmlと、Tomcatによって構成されたデフォルト、および検出されたweb-fragment.xmlファイルとアノテーションを組み合わせた結果です。指定しない場合、デフォルト値の`false`が使用されます。
`mapperContextRootRedirectEnabled`	有効にすると、Webアプリケーションのコンテキストルートへのリクエストは、デフォルトのサーブレットではなく、マッパーによって必要に応じてリダイレクト（末尾にスラッシュを追加）されます。これはより効率的ですが、コンテキストパスが存在することを確認するという副作用があります。指定しない場合、デフォルト値の`true`が使用されます。
`mapperDirectoryRedirectEnabled`	有効にすると、Webアプリケーションディレクトリへのリクエストは、デフォルトのサーブレットではなく、マッパーによって必要に応じてリダイレクト（末尾にスラッシュを追加）されます。これはより効率的ですが、ディレクトリが存在することを確認するという副作用があります。指定しない場合、デフォルト値の`false`が使用されます。
`override`	グローバルまたはHostのデフォルトコンテキストの両方の設定を無視するには、`true`に設定します。デフォルトでは、デフォルトコンテキストからの設定が使用されますが、Contextに同じ属性を明示的に設定することでオーバーライドできます。
`parallelAnnotationScanning`	`true`に設定すると、アノテーションスキャンはユーティリティエグゼキューターを使用して実行されます。これにより、サーバーの負荷が高くなる代わりに、並列でスキャン処理を実行してデプロイ時間を改善できます。指定しない場合、デフォルトの`false`が使用されます。
`path`	このWebアプリケーションのコンテキストパス。これは、処理のために適切なWebアプリケーションを選択するために、各リクエストURIの先頭と照合されます。特定のHost内のすべてのコンテキストパスは一意である必要があります。空の文字列（""）のコンテキストパスを指定した場合、このHostのデフォルトのWebアプリケーションを定義することになり、他のコンテキストに割り当てられていないすべてのリクエストを処理します。この属性は、server.xmlでContextを静的に定義する場合にのみ使用する必要があります。他のすべての状況では、パスは.xmlコンテキストファイルまたは`docBase`に使用されるファイル名から推測されます。 server.xmlでContextを静的に定義する場合でも、`docBase`がHostの`appBase`の下にない場合、または`deployOnStartup`と`autoDeploy`の両方が`false`でない限り、この属性を設定しないでください。この規則に従わないと、二重デプロイが発生する可能性があります。
`preemptiveAuthentication`	`true`に設定し、ユーザーがセキュリティ制約によって保護されていないリソースの資格情報を提示した場合、認証者がプリエンプティブ認証をサポートしている場合（Tomcatに付属の標準認証者はサポートしています）、ユーザーの資格情報が処理されます。指定しない場合、デフォルトの`false`が使用されます。
`privileged`	このコンテキストがマネージャーサーブレットのようなコンテナサーブレットを使用できるようにするには、`true`に設定します。`privileged`属性を使用すると、コンテキストの親クラスローダーが共有クラスローダーではなく、サーバークラスローダーに変更されます。デフォルトのインストールでは、共通クラスローダーがサーバークラスローダーと共有クラスローダーの両方に使用されることに注意してください。
`reloadable`	Catalinaが`/WEB-INF/classes/`および`/WEB-INF/lib`のクラスの変更を監視し、変更が検出された場合にWebアプリケーションを自動的にリロードするようにするには、`true`に設定します。この機能はアプリケーション開発中に非常に便利ですが、実行時のオーバーヘッドが大きいため、デプロイされた本番アプリケーションでの使用は推奨されません。そのため、この属性のデフォルト設定はfalseです。ただし、Manager Webアプリケーションを使用して、デプロイされたアプリケーションの再読み込みをオンデマンドでトリガーできます。
`resourceOnlyServlets`	リソースが存在することを期待するサーブレットの名前（`/WEB-INF/web.xml`で使用されているもの）をコンマ区切りでリストします。これにより、リソースが存在することを期待するサーブレット（JSPサーブレットなど）に関連付けられたウェルカムファイルが、リソースが存在しない場合には使用されないことが保証されます。これにより、Servlet 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アプリケーションがセッションを取得すると、同じホスト上の他のWebアプリケーションで、同じく`sessionCookiePath="/"`で設定されている場合、後続のすべてのセッションは常に同じセッション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はフォワード後にラップされたレスポンスをクローズする代わりに、中断します。指定されていない場合、フラグのデフォルト値は`false`です。
`swallowAbortedUploads`	Tomcatが中断されたアップロードの追加のリクエストボディデータを読み込まず、代わりにクライアント接続を中断する場合は、`false`に設定します。この設定は、以下の状況で使用されます。リクエストボディのサイズが、コネクタで設定された`maxPostSize`よりも大きい場合マルチパートアップロードのサイズ制限に達した場合サーブレットがレスポンスステータスを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`に設定すると、パフォーマンスが低下します。
`useBloomFilterForArchives`	非推奨: これが`true`の場合、ブルームフィルターを使用してアーカイブの検索を高速化します。これは、非常に大量のJARを含むWebアプリケーションのデプロイ速度を向上させるのに役立ちます。指定されていない場合、デフォルト値の`false`が使用されます。この値は、リソースのarchiveIndexStrategyでオーバーライドできます。
`useHttpOnly`	クライアント側のスクリプトがセッションIDにアクセスするのを防ぐために、セッションクッキーにHttpOnlyフラグを設定する必要がありますか？デフォルトは`true`です。
`usePartitioned`	セッションクッキーにPartitionedフラグを設定する必要がありますか？デフォルトは`false`です。注: CHIPSの一部としてパーティション分割されたクッキーを示すために使用される属性の名前は、RFCによって定義されておらず、同等の機能がRFCに含まれると、後方互換性のない方法で変更される可能性があります。
`useRelativeRedirects`	`jakarta.servlet.http.HttpServletResponse#sendRedirect(String)`の呼び出しによって生成されたHTTP 1.1以降のlocationヘッダーで、相対リダイレクトを使用するか絶対リダイレクトを使用するかを制御します。相対リダイレクトの方が効率的ですが、コンテキストパスを変更するリバースプロキシでは動作しない場合があります。複数の問題が発生するため、リバースプロキシを使用してコンテキストパスを変更することはお勧めしません。絶対リダイレクトはコンテキストパスを変更するリバースプロキシでは動作するはずですが、フィルターがスキームやポートを変更している場合、`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はクッキーによって提供されますセッションクッキーのパスは{@code /}です指定されていない場合、デフォルト値の`true`が使用されます。
`wrapperClass`	このコンテキストで管理されるサーブレットに使用される`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 です。これは、(上記にリストされた共通属性に加えて) 次の追加属性をサポートします。

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`addWebinfClassesResources`	この属性は、WebアプリケーションJARファイル内の`META-INF/resources`から静的リソースが提供されることに加えて、`WEB-INF/classes/META-INF/resources`からも静的リソースが提供されるかどうかを制御します。これは、メジャーバージョンが3以上のWebアプリケーションにのみ適用されます。これはServlet 3仕様に対する独自の拡張機能であるため、デフォルトでは無効になっています。この機能を有効にするには、属性を`true`に設定します。
`antiResourceLocking`	`true`の場合、Tomcatはファイルのロックを防ぎます。これにより、アプリケーションの起動時間が大幅に短縮されますが、ファイルのロックが発生する可能性のあるプラットフォームまたは構成で、完全なWebアプリのホットデプロイとアンデプロイが可能になります。指定されていない場合、デフォルト値は`false`です。これを`true`に設定すると、実行中のサーバーでのJSPのリロードの無効化など、いくつかの副作用があることに注意してください。 Bugzilla 37668を参照してください。 Host (デフォルトでは`webapps`ディレクトリ) の`appBase`外にあるアプリケーションでこのフラグを`true`に設定すると、Tomcatのシャットダウン時にアプリケーションが削除されることに注意してください。おそらくこれを行いたくないので、Hostの`appBase`外にあるWebアプリケーションでantiResourceLocking=trueを設定する前に、よく考えてください。
`clearReferencesHttpClientKeepAliveThread`	`true`であり、このWebアプリケーションによって`sun.net.www.http.HttpClient`キープアライブタイマースレッドが開始されていて、まだ実行中の場合、Tomcatは、メモリリークを防ぐために、そのスレッドのコンテキストクラスローダーをWebアプリケーションクラスローダーからWebアプリケーションクラスローダーの親に変更します。キープアライブタイマースレッドは、すべてのキープアライブが期限切れになると自動的に停止しますが、ビジーなシステムではしばらく停止しない可能性があることに注意してください。指定されていない場合、デフォルト値の`true`が使用されます。
`clearReferencesObjectStreamClassCaches`	`true`の場合、Webアプリケーションが停止した際に、Tomcatはシリアライズに使用される`ObjectStreamClass`クラス内で、そのWebアプリケーションによってロードされたクラスへの`SoftReference`を探し、見つけた`SoftReference`をクリアします。この機能は、`SoftReference`を特定するためにリフレクションを使用するため、コマンドラインオプション`-XaddExports:java.base/java.io=ALL-UNNAMED`を設定する必要があります。指定しない場合、デフォルト値の`true`が使用されます。 `ObjectStreamClass`に関連するメモリリークは、Java 19以降、Java 17.0.4以降、およびJava 11.0.16以降で修正されています。修正が含まれるJavaのバージョンで実行している場合、このチェックは無効になります。
`clearReferencesRmiTargets`	`true`の場合、TomcatはRMIターゲットに関連するメモリリークを探し、見つけたものをクリアします。この機能は、リークを特定するためにリフレクションを使用するため、コマンドラインオプション`-XaddExports:java.rmi/sun.rmi.transport=ALL-UNNAMED`を設定する必要があります。メモリリークがないアプリケーションは、この属性を`false`に設定しても正しく動作するはずです。指定しない場合、デフォルト値の`true`が使用されます。
`clearReferencesStopThreads`	`true`の場合、TomcatはWebアプリケーションによって開始されたスレッドを終了しようとします。スレッドの停止は、(正当な理由で)非推奨となった`Thread.stop()`メソッドを介して実行されるため、不安定になる可能性があります。そのため、これを有効にすることは、開発環境での最後の手段と見なすべきであり、本番環境では推奨されません。指定しない場合、デフォルト値の`false`が使用されます。この機能を有効にすると、エグゼキュータスレッドが正常に停止するまでに最大2秒間待機し、それでも残っているスレッドに対して`Thread.stop()`が呼び出されるため、Webアプリケーションの停止に最大2秒長くかかる場合があります。
`clearReferencesStopTimerThreads`	`true`の場合、TomcatはWebアプリケーションによって開始された`java.util.Timer`スレッドを終了しようとします。標準のスレッドとは異なり、タイマースレッドは安全に停止できますが、アプリケーションに副作用が残る可能性はあります。指定しない場合、デフォルト値の`false`が使用されます。
`clearReferencesThreadLocals`	`true`の場合、TomcatはWebアプリケーションによってロードされたクラスが設定された`java.lang.ThreadLocal`変数をクリアしようとします。指定しない場合、デフォルト値の`true`が使用されます。
`copyXML`	アプリケーション内部（`/META-INF/context.xml`に配置）に埋め込まれたコンテキスト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`が使用されます。
`renewThreadsWhenStoppingContext`	`true`の場合、このコンテキストが停止すると、Tomcatはこのコンテキストの処理に使用されたスレッドプールからすべてのスレッドを更新します。これには、`server.xml`で`ThreadLocalLeakPreventionListener`が構成されていること、および`Executor`の`threadRenewalDelay`プロパティが>=0であることも必要です。指定しない場合、デフォルト値の`true`が使用されます。
`skipMemoryLeakChecksOnJvmShutdown`	`true`の場合、WebアプリケーションがJVMシャットダウンの一部として停止した場合、TomcatはWebアプリケーションが停止したときに通常のメモリリークチェックを実行しません。指定しない場合、デフォルト値の`false`が使用されます。
`unloadDelay`	コンテナがサーブレットのアンロードを待機するミリ秒数。指定しない場合、デフォルト値は`2000`ミリ秒です。
`unpackWAR`	`false`の場合、所有HostのunpackWARs属性が上書きされ、WARファイルは展開されません。`true`の場合、所有HostのunpackWARs属性の値によって、WARが展開されるかどうかが決定されます。指定しない場合、デフォルト値は`true`です。
`useNaming`	Jakarta EEプラットフォームの規約に準拠したこのWebアプリケーション用のJNDI `InitialContext`をCatalinaで有効にするには、`true`（デフォルト）に設定します。
`workDir`	関連付けられたWebアプリケーション内のサーブレットが一時的な読み書きに使用するために、このコンテキストによって提供されるスクラッチディレクトリへのパス名。このディレクトリは、Servlet仕様で説明されているように、`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 - Webアプリケーション内のJARファイルとクラスファイルディレクトリをスキャンするために使用されるJar Scannerを構成します。通常、Webアプリケーションの開始時に、Webアプリケーションの初期化の一部として処理する必要があるTLDやweb-fragment.xmlファイルなどの構成ファイルを特定するために使用されます。通常、デフォルトのJar Scanner構成で十分です。

特別な機能

ロギング

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

アクセスログ

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

Engine、Host、またはContextによって処理されるすべてのリクエストのアクセスログをCatalinaに作成させるには、次のように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>要素の有効な属性は次のとおりです。

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`description`	このコンテキスト初期化パラメータのオプションの人間の可読な説明。
`name`	作成するコンテキスト初期化パラメータの名前。
`override`	Webアプリケーションのデプロイメント記述子にある同じパラメータ名の`<context-param>`が、ここで指定された値を上書きすることを望まない場合は、これを`false`に設定します。デフォルトでは、上書きが許可されています。
`値`	`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>要素の有効な属性は次のとおりです。

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`description`	この環境エントリのオプションの人間が読める説明。
`name`	`java:comp/env`コンテキストを基準とした、作成する環境エントリの名前。
`override`	Webアプリケーションのデプロイメント記述子にある同じ環境エントリ名の`<env-entry>`が、ここで指定された値を上書きすることを望まない場合は、これを`false`に設定します。デフォルトでは、上書きが許可されています。
`タイプ`	この環境エントリに対してWebアプリケーションが期待する完全修飾Javaクラス名。Webアプリケーションのデプロイメント記述子内の`<env-entry-type>`の有効な値でなければなりません。
`値`	JNDIコンテキストから要求されたときにアプリケーションに提示されるパラメータ値。この値は、`type`属性で定義されたJava型に変換可能でなければなりません。

ライフサイクルリスナー

このコンテキストが開始または停止されたときに通知する必要がある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>要素の有効な属性は次のとおりです。

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`認証`	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`です。この属性を空の文字列に設定すると、無効にできます。その他のすべてのリソースタイプの場合、デフォルトは定義されておらず、デフォルトではcloseメソッドは呼び出されません。
`description`	このリソースのオプションの人間が読める説明。
`name`	`java:comp/env`コンテキストを基準とした、作成するリソースの名前。
`スコープ`	このリソースマネージャーを通じて取得した接続を共有できるかどうかを指定します。この属性の値は、`Shareable`または`Unshareable`である必要があります。デフォルトでは、接続は共有可能であると想定されます。
`シングルトン`	このリソース定義がシングルトンリソース、つまりリソースのインスタンスが1つしかない場合のものかどうかを指定します。この属性が`true`の場合、このリソースに対する複数のJNDIルックアップは同じオブジェクトを返します。この属性が`false`の場合、このリソースに対する複数のJNDIルックアップは異なるオブジェクトを返します。`javax.sql.DataSource`リソースでDataSourceのJMX登録を有効にするには、この属性は`true`である必要があります。この属性の値は`true`または`false`である必要があります。デフォルトでは、この属性は`true`です。
`タイプ`	このリソースをルックアップするときに、Webアプリケーションが期待する完全修飾Javaクラス名。

リソースリンク

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

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

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

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

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`グローバル`	グローバルJNDIコンテキスト内のリンクされたグローバルリソースの名前。
`name`	`java:comp/env`コンテキストを基準とした、作成するリソースリンクの名前。
`タイプ`	このリソースリンクをルックアップするときに、Webアプリケーションが期待する完全修飾Javaクラス名。
`ファクトリ`	これらのオブジェクトを作成するクラスの完全修飾Javaクラス名。このクラスは、`javax.naming.spi.ObjectFactory`インターフェースを実装する必要があります。

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

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`ユーザー名`	リンクされたグローバルDataSourceでの`getConnection(username, password)`呼び出しの`username`値。
`パスワード`	リンクされたグローバル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>要素の有効な属性は次のとおりです。

単一の WAR ファイルまたはディレクトリを使用する複数のコンテキストを定義するには、ベースファイル名に関連付けられていないパスを持つ Context を作成するために、上記の命名セクションで説明されているオプションのいずれかを使用します。	Context のすべての実装は、次の属性をサポートしています
`ファクトリ`	JNDIオブジェクトファクトリのクラス名。

Context コンテナ

目次

はじめに

並行デプロイメント

命名

コンテキストの定義

属性

共通属性

標準実装

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

特別な機能

ロギング

アクセスログ

自動コンテキスト構成

コンテキストパラメータ

環境エントリ

ライフサイクルリスナー

リクエストフィルター

リソース定義

リソースリンク

トランザクション