Tomcatがcontext.xmlファイルの削除を好むのはなぜですか？

私は職場でWebベースのJavaアプリケーションを開発していますが、（明らかに）開発中にローカルで実行する必要があります。私はTomcatのドキュメントを理解し、適切なcontext.xmlファイルを持っています/etc/tomcat6/Catalina/localhost/が、Tomcatはそれを削除することをたびたび決定します！つまり、Tomcatを元に戻し、再起動する必要があります。

なぜこれを行うのですか？私はそれについてTomcatのドキュメントを検索しましたが、賢明な人はいません。

（ああそうです：実際には呼び出されませんcontext.xmlがowners.xml、それがこのアプリケーションのHTTPパスプレフィックスであるためです。）

更新

Tomcatの実行中にTomcatがファイルを削除するのを見ました。バグを報告する必要があると思います...

簡単な要約：Tomcatがコンテキストファイルの削除を含むコンテキストをアンデプロイするいくつかの条件（warファイルの変更、webappの削除、または新しいコンテンツでの置換など）があります。

詳細：tomcatがautoDeployment（.xml記述子の変更をチェックし、webappディレクトリの変更をチェックすることを意味します）を行うかどうかは、以下によって決まります。

1. $ CATALINA_HOME / conf / server.xmlセクションにローカライズされたserver.xml：

   <Host name = "localhost" appBase = "webapps" unpackWARs = "true" autoDeploy = " true" xmlValidation = "false" xmlNamespaceAware = "false">

2. コンテキストファイルでこのプロパティを設定して、値をオーバーロードすることもできます

autoDeploy = trueの場合にドキュメントを引用すると、コンテキストファイルが削除される場合があります。

• WARファイルを削除すると、関連する展開ディレクトリ、コンテキストファイル、および作業ディレクトリが削除され、アプリケーションのアンデプロイがトリガーされます。
• ディレクトリを削除すると、関連するコンテキストファイルと作業ディレクトリが削除され、アプリケーションのアンデプロイがトリガーされます。
• WARファイルを更新すると、関連する展開ディレクトリ、コンテキストファイル、および作業ディレクトリが削除され、アプリケーションのアンデプロイがトリガーされます。
• ディレクトリの内容ではなくディレクトリを更新すると、関連するコンテキストファイルと作業ディレクトリが削除され、アプリケーションのアンデプロイがトリガーされます。

徹底的な詳細：http : //tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment

たとえば、実稼働環境でautoDeploy機能が必要ない場合は、conf / Catalina / localhostコンテキストファイルの次の属性を考慮することができます。

• autoDeploy = "false"
• そしてdeployXML = "false"

autoDeploy = "false"は、アプリケーションcontext.xml（META-INF内）がautoDeployのserver.xml設定をオーバーライドできるため、単独では機能しない場合があります。

• アプリケーションのMETA-INF / context.xmlは、開発環境でautoDeployとともに使用されます
• 運用環境のconf / Catalina / localhostコンテキスト、autoDeployなし。

deployXML属性のドキュメント属性のドキュメントは読む価値があります（§標準実装）。

徹底的なautoDeployユーザーケース、およびコンテキストが削除された場合（つまり、アプリケーションがアンデプロイされた場合、ユーザーケースが文書化されている）は、ここにあります。

なぜビットに答えないでください。

ただし、このリンクではautoDeploy="false"、server.xml

私は正直これを行うTomcatの背後にある理由がわからないが、次のXML属性をコンテキスト要素に追加してみてください

reloadable="false"

したがって、コンテキストは次のようになります。

<Context path="/" docBase="/some/path/name" reloadable="false">
<!-- Context related stuff -->
</Context>

これにより、Tomcatがファイルを削除しないようにする必要があります

これは古いスレッドであることに気付きましたが、この問題を解決するために見つけたものを共有すると思いました...

私は、アプリケーション用のwarファイルの新しいコピーをデプロイするたびに、Tomcatのデスクトップバージョンのcontext.xmlファイルでまったく同じ問題を抱えていました。

問題は、ファイルシステム上でこのファイルに直接変更を加えていたためです。問題を修正したのは、Eclipseエディターでcontext.xmlファイルを編集することでした。私のEclipseの内部には、「servers」プロジェクトがあり、それを展開すると、context.xmlやserver.xmlなどのいくつかのファイルを見ることができます。ファイルシステムにアクセスする代わりに、ここからファイルを変更すると、変更は保持されるようです。

この解決策は、次のスレッドで見つかりました：https : //www.liferay.com/community/forums/-/message_boards/message/16511799

これが他の誰かに役立つことを願っています！

-スティーブン

タイトルで説明されている一般的な問題は、コンテキストを削除せずに戦争から再デプロイすることでカバーされていますが、現時点ではまだ未解決の問題です。

コンテキストを削除しない再デプロイと、アンデプロイがコンテキストを削除するアンデプロイ後にデプロイすることには、認識されている違いがあります。ドキュメントは古く、マネージャーGUIは再デプロイをまだサポートしていません。

サーバー内のアプリに異なる値、たとえばアップロードされたファイルを保存するパスが必要な場合があります。開発者環境mabeには、次のようなものがあります。

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" reloadable="false">
     <Parameter name="rutaTrabajo" value="C:\Larry\Proyectos\app\rutaTrabajoxx" override="true"/>
</Context>

ただし、サーバーではパスが異なります。

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/App/rutaTrabajo" override="true"/>
</Context>

conf / Catalina / localhostからcontext.xml（meapp.xml）を削除するtomcatも同じ問題があります

解決するには、context.xml.defaultを使用し、同じパスでcontext.xml.defaultというファイルを作成し、保持したいput構成内に作成します：

 cat context.xml.default
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/ParkMeServer" allowCasualMultipartParsing="true" >
     <Parameter name="rutaTrabajo" value="/usr/share/ParkiMeApp/rutaTrabajo" override="true"/>
</Context>

そのため、アプリを再デプロイするときに、confirパラメーターがまだそこにあります。