0

.properties ファイルを外部化するために、現在、C:\test\UI\properties などのファイル システムに保存しており、上記のファイルの場所を指す環境変数 $PROP_LOCATION を作成しました。したがって、プロパティを変更する必要があるときはいつでも、その場所に移動してプロパティを編集し、アプリケーションを更新するだけです。それは魅力のように機能します。

これが最善の方法ですか?または、プロパティファイルをwarファイルから除外するために専門家が私に提案する他の方法はありますか?

注:環境変数の1つが見つからない場合、別の環境変数をチェックする「if」条件があるため、上記のことはUNIX環境とWindows環境の両方で正常に機能します。

4

3 に答える 3

1

プロパティ ファイルをアプリケーションにパッケージ化することが最も理にかなっていることに同意します。そうしない正当な理由がある場合、展開時にアプリケーションがアクセスでき、インターネットに公開されていない場所にファイルが配置されている限り、ソリューションは問題ないようです。

私はあなたに似たようなことをしています。私が実行しているアプリケーションには、ユーザーに見てもらいたいアナウンスやその他のメッセージのページがありますが、私や他の人がこれらのメッセージを編集しやすくするために、メッセージはサーバー上の別の場所から読み込まれます。 Tomcat フォルダにあります。その後、再デプロイしなくてもメッセージを簡単に編集できます。

于 2012-11-21T13:43:48.883 に答える
1

通常、ディレクトリをクラスパスに追加して、外部プロパティ ファイルを参照します。

たとえば、example.properties がパス C:\test\UI\properties ディレクトリにある場合、次のように JVM を呼び出します。

java -classpath C:\test\UI\properties MyJavaProgram

Java コード内では、次のメカニズムを介してプロパティをロードできます。

Properties p = new Properties();
p.load(getClass().getClassLoader().getResourceAsStream("/example.properties"));
于 2012-11-21T13:41:04.363 に答える
0

春の ReloadableResourceBundleMessageSource を使用することをお勧めします

それをチェックしてください:http://static.springsource.org/spring/docs/1.2.9/api/org/springframework/context/support/ReloadableResourceBundleMessageSource.html

また、プロパティ ファイルの配置に関しては、それらをアプリケーションの外部に保持することはお勧めできません。それらは論理的にアプリケーションの一部であるため、とにかく war でパッケージ化する必要があります。

また、アプリケーションをリロードしているため、プロパティが変更されるたびに、maven タスクを使用してサーバー上でアプリをビルド、デプロイ、およびリロードできます。

于 2012-11-21T13:30:36.437 に答える