2

最近、コア サーブレット アプリケーションのコア機能を jar ファイルに分離しました。この jar ファイルは tomcat の lib フォルダにデプロイされ、アプリケーション (サーブレット、jsps、プロパティ ファイルなど) は war ファイルとして個別にデプロイされます。

jar ファイルには特定のプロパティ ファイルが必要です。これらのプロパティ ファイルは、war ファイルの "src" フォルダーのすぐ下 (つまり、クラス階層の最上位) に配置します。

以前は、すべてが同じプロジェクトにあり、1 つの war ファイルにデプロイされていました。プロパティ ファイルは、関連するクラスからアクセスできました。これらのクラスが jar にデプロイされると、war ファイル (つまり、デプロイされた Web アプリケーション) にあるプロパティ ファイルが表示されなくなります。

ここで何が欠けているのでしょうか? プロパティファイルをロードする方法の例:

properties.load(getClass().getResourceAsStream("/appconfig.properties"));

お時間をいただきありがとうございます。

4

2 に答える 2

9

クラス独自のクラスローダーで取得しないでください。クラスは Tomcat によって管理されるようになったため、Web アプリケーション固有のリソースではなく、Tomcat の内部リソースについてのみ認識します。現在のスレッドのコンテキスト クラスローダーで取得する必要があります。そのクラスローダーは、現在の webapp 専用のすべてのリソースを認識しています。

properties.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("appconfig.properties"));

これに関係なく、グローバル アプリ構成を表すこのようなプロパティ ファイルの適切な場所は、WAR ファイル内ではありません。プロパティ ファイルを Tomcat および WAR ファイルの外側の固定パスに配置し、その固定パスをshared.loaderTomcat のプロパティに追加し/conf/catalina.propertiesて、クラスパスの一部にする必要があります。これにより、WAR全体を再構築/再デプロイする必要なく、構成ファイルを自由に編集できます。コンテキストクラスローダーを使用してロードする必要があることに注意してください。

于 2011-08-16T16:16:26.973 に答える
1

はい、それは機能しません。Tomcat lib フォルダー内の jar が、webapp のクラスについて何も知らない別のクラスローダーによって読み込まれるためです。つまり、Tomcat lib は、webapp クラスローダーの親クラスローダーです (webapp ごとに 1 つ作成されます)。

機能させたい場合は、プロパティファイルを外部の場所に配置し、絶対ファイルパスを介して tomcat lib 内の jar に認識させるか、jar を webapp の lib 内に戻すことができます。

Tomcat サイトからの参照を次に示します。

http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html

通常、環境変数は $CATALINA_HOME を識別するために使用され、絶対パスのハードコーディングを避けるために相対ファイル パスの前に付けられます。

String catalinaHome = System.getProperty("CATALINA_HOME");
properties.load(new FileInputStream(new File(catalinaHome + "/path/to/appconfig.properties")));
于 2011-08-16T16:09:31.137 に答える