Apache Tomcat 11

停止したアプリケーションに再起動を指示し、再度利用可能にします。停止と開始は、例えば、アプリケーションが必要とするデータベースが一時的に利用できなくなった場合に役立ちます。ユーザーに継続的にデータベース例外を発生させるよりも、このデータベースに依存するウェブアプリケーションを停止する方が通常は良い方法です。

このコマンドが成功した場合、次のようなメッセージが表示されます

OK - Started application at context path /examples

それ以外の場合、メッセージはFAILで始まり、エラーメッセージが含まれます。問題の考えられる原因には次のようなものがあります

• 例外が発生しました

  ウェブアプリケーションの開始中に例外が発生しました。詳細についてはTomcatのログを確認してください。

• 無効なコンテキストパスが指定されました

  コンテキストパスはスラッシュ文字で始まる必要があります。ただし、ROOTウェブアプリケーションを参照している場合は、コンテキストパスはゼロ長文字列である必要があります。

• パス /foo にコンテキストが存在しません

  指定されたコンテキストパスにデプロイされたアプリケーションはありません。

• コンテキストパスが指定されていません

  pathパラメーターは必須です。

既存のアプリケーションに自身を利用不可にするよう指示しますが、デプロイ状態は維持します。アプリケーションが停止している間に受信したリクエストはHTTPエラー404となり、このアプリケーションはリスト表示コマンドで「停止中」と表示されます。

このコマンドが成功した場合、次のようなメッセージが表示されます

OK - Stopped application at context path /examples

それ以外の場合、メッセージはFAILで始まり、エラーメッセージが含まれます。問題の考えられる原因には次のようなものがあります

• 例外が発生しました

  ウェブアプリケーションの停止中に例外が発生しました。詳細についてはTomcatのログを確認してください。

• 無効なコンテキストパスが指定されました

  コンテキストパスはスラッシュ文字で始まる必要があります。ただし、ROOTウェブアプリケーションを参照している場合は、コンテキストパスはゼロ長文字列である必要があります。

• パス /foo にコンテキストが存在しません

  指定されたコンテキストパスにデプロイされたアプリケーションはありません。

• コンテキストパスが指定されていません

  pathパラメーターは必須です。

既存のアプリケーションに自身をシャットダウンしてリロードするよう指示します。これは、ウェブアプリケーションコンテキストがリロード可能でない場合に、/WEB-INF/classesディレクトリ内のクラスまたはプロパティファイルを更新したり、/WEB-INF/libディレクトリ内のjarファイルを追加または更新したりした場合に役立ちます。

注意: /WEB-INF/web.xmlウェブアプリケーション設定ファイルはリロード時にチェックされません。以前のweb.xml設定が使用されます。web.xmlファイルに変更を加えた場合は、ウェブアプリケーションを停止してから開始する必要があります。

このコマンドが成功した場合、次のようなメッセージが表示されます

OK - Reloaded application at context path /examples

それ以外の場合、メッセージはFAILで始まり、エラーメッセージが含まれます。問題の考えられる原因には次のようなものがあります

• 例外が発生しました

  ウェブアプリケーションの再起動中に例外が発生しました。詳細についてはTomcatのログを確認してください。

• 無効なコンテキストパスが指定されました

  コンテキストパスはスラッシュ文字で始まる必要があります。ただし、ROOTウェブアプリケーションを参照している場合は、コンテキストパスはゼロ長文字列である必要があります。

• パス /foo にコンテキストが存在しません

  指定されたコンテキストパスにデプロイされたアプリケーションはありません。

• コンテキストパスが指定されていません

  pathパラメーターは必須です。

• パス /foo にデプロイされたWARではリロードはサポートされていません

  現在、ウェブアプリケーションがWARファイルから直接インストールされている場合（ホストがWARファイルを展開しないように設定されている場合に発生）、アプリケーションのリロード（クラスまたはweb.xmlファイルへの変更を反映するため）はサポートされていません。これは展開されたディレクトリからウェブアプリケーションがインストールされている場合にのみ機能するため、WARファイルを使用している場合は、変更を反映させるためにアプリケーションをアンデプロイしてから再度デプロイする必要があります。

警告 - このコマンドは、この仮想ホストのappBaseディレクトリ（通常「webapps」）内にウェブアプリケーションディレクトリおよび/または「.war」ファイルが存在する場合、その内容を削除します。ウェブアプリケーションの一時作業ディレクトリも削除されます。単にアプリケーションをサービスから外したい場合は、/stopコマンドを使用してください。

既存のアプリケーションに優雅にシャットダウンするよう指示し、Tomcatから削除します（これにより、このコンテキストパスは後で再利用できるようになります）。このコマンドは、/deploy Antコマンド、およびHTMLマネージャーで利用可能な関連するデプロイ機能の論理的な反対です。

このコマンドが成功した場合、次のようなメッセージが表示されます

OK - Undeployed application at context path /examples

それ以外の場合、メッセージはFAILで始まり、エラーメッセージが含まれます。問題の考えられる原因には次のようなものがあります

• 例外が発生しました

  ウェブアプリケーションのアンデプロイ中に例外が発生しました。詳細についてはTomcatのログを確認してください。

• 無効なコンテキストパスが指定されました

  コンテキストパスはスラッシュ文字で始まる必要があります。ただし、ROOTウェブアプリケーションを参照している場合は、コンテキストパスはゼロ長文字列である必要があります。

• パス /foo にコンテキストが存在しません

  指定されたコンテキストパスにデプロイされたアプリケーションはありません。

• コンテキストパスが指定されていません pathパラメーターは必須です。

指定されたコンテキストパス:（他のウェブアプリケーションによって使用されていない必要があります）に紐付けられた新しいウェブアプリケーションをデプロイして開始します。このコマンドは、アンデプロイコマンドの論理的な反対です。

デプロイコマンドにはいくつかの異なる使用方法があります。

Context Path: /footoo
WAR or Directory URL: file:C:/path/to/foo

WAR or Directory URL: jar:file:/path/to/bar.war!/

WAR or Directory URL: foo

Context Path: /bartoo
WAR or Directory URL: bar.war

<Context path="/foobar" docBase="C:\path\to\application\foobar">
</Context>

XML Configuration file URL: file:C:/path/to/context.xml

XML Configuration file URL: file:/path/to/context.xml
WAR or Directory URL: jar:file:/path/to/bar.war!/

ローカルシステムからWARファイルをアップロードし、ホストのappBaseにインストールします。「.war」拡張子なしのWARファイル名がコンテキストパス名として使用されます。

参照ボタンを使用して、ローカルデスクトップシステムからサーバーにアップロードするWARファイルを選択します。

.WARファイルには、/META-INF/context.xmlにコンテキスト設定XMLファイルを含めることで、Tomcat固有のデプロイメント設定を含めることができます。

WARファイルのアップロードは、以下の理由で失敗する可能性があります

• アップロードされたファイルは.warである必要があります

  アップロードによるインストールは、「.war」のファイル名拡張子を持つファイルのみを受け入れます。

• WARファイルがサーバーに既に存在します

  同じ名前のWARファイルがホストのappBaseに既に存在する場合、アップロードは失敗します。既存のWARファイルをホストのappBaseからアンデプロイするか、異なる名前を使用して新しいWARファイルをアップロードしてください。

• ファイルのアップロードに失敗しました、ファイルがありません

  ファイルのアップロードに失敗しました。サーバーでファイルが受信されませんでした。

• インストールアップロード失敗、例外

  WARファイルのアップロードまたはインストールがJava例外で失敗しました。例外メッセージがリスト表示されます。

ホストがunpackWARs=trueで設定されており、WARファイルをインストールする場合、WARはホストのappBaseディレクトリ内のディレクトリに展開されます。

アプリケーションのWARまたはディレクトリがホストのappBaseディレクトリにデプロイされており、ホストがautoDeploy=trueに設定されている場合、コンテキストパスはディレクトリ名または「.war」拡張子なしのWARファイル名と一致する必要があります。

信頼できないユーザーがウェブアプリケーションを管理できる場合のセキュリティのため、ホストのdeployXMLフラグをfalseに設定できます。これにより、信頼できないユーザーが設定XMLファイルを使用してウェブアプリケーションをインストールしたり、ホストのappBase外にあるアプリケーションディレクトリや「.war」ファイルをインストールしたりすることを防ぎます。

デプロイと起動が成功した場合、次のようなメッセージが表示されます

OK - Deployed application at context path /foo

それ以外の場合、メッセージはFAILで始まり、エラーメッセージが含まれます。問題の考えられる原因には次のようなものがあります

• アプリケーションはパス /foo に既に存在します

  現在実行中のすべてのウェブアプリケーションのコンテキストパスは一意である必要があります。したがって、このコンテキストパスを使用している既存のウェブアプリケーションをアンデプロイするか、新しいウェブアプリケーションに別のコンテキストパスを選択する必要があります。

• ドキュメントベースが存在しないか、読み取り可能なディレクトリではありません

  WARまたはディレクトリのURL:フィールドで指定されたURLは、このサーバー上の「展開された」バージョンのウェブアプリケーションを含むディレクトリ、またはこのアプリケーションを含むウェブアプリケーションアーカイブ（WAR）ファイルの絶対URLを識別する必要があります。WARまたはディレクトリのURL:フィールドに入力された値を修正してください。

• 例外が発生しました

  新しいウェブアプリケーションの開始中に例外が発生しました。詳細についてはTomcatのログを確認してください。ただし、考えられる原因としては、/WEB-INF/web.xmlファイルの解析問題、またはアプリケーションイベントリスナーやフィルターの初期化時に遭遇したクラスの欠落などがあります。

• 無効なアプリケーションURLが指定されました

  指定されたWARまたはディレクトリのURL:フィールドのURLは無効でした。このようなURLはfile:で始まり、WARファイルのURLは「.war」で終わる必要があります。

• 無効なコンテキストパスが指定されました

  コンテキストパスはスラッシュ文字で始まる必要があります。ただし、ROOTウェブアプリケーションを参照している場合は、コンテキストパスは「/」文字列である必要があります。

• コンテキストパスはディレクトリまたはWARファイル名と一致する必要があります

  アプリケーションのWARまたはディレクトリがホストのappBaseディレクトリにデプロイされており、ホストがautoDeploy=trueに設定されている場合、コンテキストパスはディレクトリ名または「.war」拡張子なしのWARファイル名と一致する必要があります。

• ホストのウェブアプリケーションディレクトリ内のウェブアプリケーションのみデプロイ可能です

  ホストのdeployXMLフラグがfalseに設定されている場合、ホストのappBaseディレクトリ外にウェブアプリケーションディレクトリまたは「.war」ファイルをインストールしようとすると、このエラーが発生します。

「メモリリークの発見」診断は、完全なガベージコレクションをトリガーします。本番システムでの使用は極めて慎重に行う必要があります。

「メモリリークの発見」診断は、停止、リロード、またはアンデプロイされた際にメモリリークを引き起こしたウェブアプリケーションを特定しようとします。結果は常にプロファイラで確認する必要があります。この診断は、StandardHost実装によって提供される追加機能を使用します。StandardHostを拡張しないカスタムホストを使用している場合は機能しません。

この診断では、停止、リロード、またはアンデプロイされたウェブアプリケーションのコンテキストパスがリスト表示されますが、以前の実行からのクラスがまだメモリ内に存在し、メモリリークとなっているものが対象です。アプリケーションが複数回リロードされた場合、複数回リストされる可能性があります。

Javaコードから明示的に完全なガベージコレクションをトリガーすることは、信頼できないとされています。さらに、使用するJVMによっては、-XX:+DisableExplicitGCのように明示的なGCトリガーを無効にするオプションがあります。診断が正常に完全なGCを実行したことを確認したい場合は、GCロギング、JConsoleなどのツールを使用して確認する必要があります。