11

現在作業中のRMIアプリケーションのコードベースを設定する必要があり、最初に使用してこれを正常に実行しました

try{
  ResourceBundle config = ResourceBundle.getBundle("myApp");
  String codeBaseUrl = config.getString("codeBaseUrl");
  System.setProperty("java.rmi.server.codebase", codeBaseUrl);
} catch (Exception e) {
  e.printStackTrace();
}

後で使用する

java -Djava.rmi.server.codebase=http://192.168.1.1/path/to/codebase ...

コマンドラインで。

これらのアプローチはどちらも、再コンパイルせずにコードベースを変更できますが、System.setPropertyアプローチでは、コードベースをプロパティファイルにバンドルして、同じ起動コマンドを使用できます。

私がこれについて読んだチュートリアル/ドキュメントのほとんどは、-Dアプローチを使用しており、これがベストプラクティスとして受け入れられていると信じていますが、なぜ他のものよりも使用する必要があるのか​​を説明するものを見つけることができませんでした。

-Dは、コードベースなどのシステムプロパティを設定するためのベストプラクティスと見なされますか？また、これによってどのようなメリットが得られますか/どのような落とし穴が回避されますか？

4

4 に答える 4

7

（編集済み-質問を読み間違えました）

2つの比較：

  • -D構成可能です-実行時に指定されます
  • 経由のリソースバンドルSystem.setProperty()は引き続き「ランタイム」ですが、起動コマンドを超えて存在するファイルを介して編集されます

まず、実行時に設定を指定して柔軟な動作を駆動することは、動作をハードコーディングするよりも常に望ましいです（動作が実際に柔軟でない場合を除きます。つまり、そうすることに価値がない限り、構成を使用しないでください）。

ファイルを使用することの主な欠点は、パスワードなどの機密データが含まれている可能性があり、システム管理者がディスク上に永続的に存在することを望まないことです。パスワードがスタートアップコマンドの一部として入力された場合、それは一時的ではるかに安全です（セッションコマンドの履歴は耐えられません）。

ファイルを使用する利点は、正しい設定を確立でき、それらがファイルに残ることです。ソース管理を介してファイルを管理することもできます。


もう1つのさらに安全なオプションがあります。それは、スタートアップにコマンドラインで入力するパスワードを要求させることです。これは痕跡を残しません。

于 2012-09-27T01:21:04.457 に答える
4

System.setPropertyを使用します（一部のプロパティでは遅すぎる可能性があるため、アプリケーションの最上部にあります）が、構成ファイルから情報を取得します。

ほとんどすでにそれを行っていますが、ハードコードされたいくつかのキーだけでなく、任意のプロパティを設定することもできます。

これを、アプリがすでに使用している構成ファイルと組み合わせるのが好きです。この構成ファイルには、他の（System.properties以外の）設定も含まれています。システムプロパティの前に-Dを付けることで2つを区別します（コマンドラインの場合と同じように）。

 # some configuration
 a.b.c = xxx

 # RMI settings
 -Djava.rmi.server.codebase = http://192.168.1.1/path/to/codebase

このプロパティファイルを見つけるデフォルトの場所がありますが、コマンドラインスイッチを使用してオーバーライドできます（これにより、異なる構成を切り替えたり、コードを複数インストールしたりすることが簡単にできます）。

ファイルがあると、ドキュメントとしても機能するという追加の利点があります（使用可能なオプション、デフォルトは何かなど）。

Javaに、メモリやクラスパスなどの他のJVM設定とともに、プロパティファイルからシステムプロパティを取得する機能が組み込まれていることを本当に望んでいます。現在、JavaまたはOS固有のシェルラッパーのいずれかで、すべてを自分で行う必要があります。

于 2012-09-27T01:45:10.090 に答える
2

特別な理由がない限り (機密情報の公開を避ける、いじくり回すのを防ぐなど)、System.setProperty を使用してプロパティを追加するのではなく、「-D」オプションを使用することをお勧めします。

  • よりシンプルです（コードが少ない）
  • アプリケーションに依存しない方法で直接設定できます
  • アプリケーションコードがシステムプロパティを設定する前に、初期化中に何かがシステムプロパティを読み取るという問題を回避します。

もう 1 つの推奨事項は、システム プロパティを多数のアプリケーション固有のプロパティのゴミ捨て場として使用しないことです。多くのアプリケーション構成プロパティがある場合は、別の Properties オブジェクト (またはより複雑なもの) を使用し、別のプロパティ ファイル (またはより複雑なもの) からロードします。他の人はこれについて私に同意しないかもしれませんが、私はこれがより良いアプローチであることがわかりました.

(しかし、明らかに、システム プロパティを参照する標準またはサード パーティのサブシステムを使用している場合は、それを行う必要があります。)

于 2012-09-27T01:57:02.173 に答える
1

実行時に引数を渡すことで、ステートメントをコードにハードコーディングしなくても、開発環境と本番環境（特に）環境用の単一のコードベースを簡単に作成できるためです。たとえば、開発では192.168.0.1のサーバーに接続し、本番環境では10.0.1.1に接続することができます。System.setPropertyを使用してハードコーディングすることでこの結果を達成するには、条件付きステートメントが必要であり、これは面倒になる可能性があります。

通常、環境ごとにアプリを再コンパイルする必要はないため、実行時に引数を渡すか、システムごとに変更される可能性のあるある種のプロパティファイルを使用するのが最も便利な場合がよくあります。

于 2012-09-27T01:24:08.697 に答える