私はJavaライブラリ内のすべてのハードコードされた値を取り除く過程にあり、実行時の構成を処理するのにどのフレームワークが(ゼロまたはゼロに近い構成に関して)最適であるか疑問に思っていましたか?XMLベースの構成ファイルが好きですが、必須ではありません。
フレームワークの実務経験がある場合にのみ返信してください。私は例を探していませんが、経験しています...
私はJavaライブラリ内のすべてのハードコードされた値を取り除く過程にあり、実行時の構成を処理するのにどのフレームワークが(ゼロまたはゼロに近い構成に関して)最適であるか疑問に思っていましたか?XMLベースの構成ファイルが好きですが、必須ではありません。
フレームワークの実務経験がある場合にのみ返信してください。私は例を探していませんが、経験しています...
ApacheCommonsConfigurationはうまく機能します。プロパティ、XML、JNDIなどを含むさまざまな形式で構成をバックエンドに保存することをサポートします。使いやすく、拡張も簡単です。それを最大限に活用するには、ファクトリを使用して構成を取得し、その後は構成インターフェイスを使用します。
ストレートプロパティファイルと区別するCommonsConfigurationの2つの機能は、一般的な型(int、float、String配列)への自動変換をサポートし、プロパティの置換をサポートすることです。
server.host=myHost
server.url=http://${server.host}/somePath
ハードコードされた値が単純なキーと値のペアである場合は、java.util.Propertiesを確認する必要があります。これは、xmlよりもはるかに単純で、使いやすく、実装するのは非常に簡単です。
Javaを使用していて、ディスクに保存または取得するデータがキーと値のペアとしてモデル化されている場合(あなたの場合のように聞こえます)、これ以上の解決策は想像できません。
私は、大きなプロジェクトで小さなパッケージを簡単に構成するために、またプロジェクト全体でよりグローバルな構成としてプロパティファイルを使用しましたが、問題が発生したことはありません。
もちろん、これにはサードパーティのライブラリを使用する必要がないという大きな利点があります。
さまざまなオプションがあります:
さまざまなユーザーからのフィードバックについては、Commons Configuration と JFig および JConfig の比較および JFigを使用したアプリケーションの構成をお読みになることをお勧めします。
個人的には、jConfig を使用したことがありますが、これは良い経験でした。
これを使用しています。プロパティ ファイルだけで処理する方がはるかに簡単ですが、より複雑なデータ コモンズ構成を表す必要がある場合は、これを実行してプロパティ ファイルを読み取ることもできます。
複雑なことをしていない場合は、プロパティ ファイルに固執します。
高度な (そしてタイプセーフな) ことをしたい場合は、これを見てください: http://www.ibm.com/developerworks/java/library/j-configint/index.html
Intelligent Parameter Utilization Tool (InPUT、ページ)を使用すると、ほぼすべての (ハードコードされた) 決定をパラメーターとして XML ベースの構成ファイルに外部化できます。これは、一般性と関心の分離に関する既存の構成ツールの認識された欠陥への対応として、2012 年の初めに開始されました。
InPUT は、クラス マッピングへの複雑な記述子の定義、またはランダム化された構成のスポーンと検証などの機能を使用して、プログラミング言語に依存しない実験データ (入力 - 出力) の定式化を可能にするため、ほとんどのユース ケースが必要とするよりもおそらく強力です。定義済みの値の範囲 (モンテカルロ シミュレーションなどのテストおよび研究用)。サブパラメーター、パラメーター値の相対的な制限 (数値パラメーター a > パラメーター b)などを使用してパラメーターを定義できます。
まだベータ版ですが、かなり安定しており、研究、実験の構成と文書化、および教育目的で使用しています。他の言語 (パイプ内の C++ アダプター) で使用できるようになると、他の研究者/実践者は、C++ で同じアルゴリズムの実装を実行している記述子を再利用できます (コード マッピングの概念を使用)。そうすれば、実験結果を検証したり、プログラムをより簡単に移行したりできます。ドキュメントはまだ作業中ですが、いくつかの例がこのページで利用できます。InPUT はオープンソースソフトウェアです。
興味のある方は、Conceptual Research Paperをご覧ください。
私はほとんどの場合、アプリケーション固有の構成クラスにラップされたjava.util.Properties
(または他の言語やフレームワークの同様のクラス)を使用する傾向がありますが、これに代わるものやバリエーションに非常に興味があります。特に、グラフィカルな構成ダイアログや構成データの複数のビューが関係している場合は、少し注意が必要です。
残念ながら、Java 用の特定のライブラリを使用した経験はありません (自分で作成したものを除く) が、ポインタをいただければ幸いです。
アップデート
わかった。3 つめはSpring Java Configuration Projectです。
数週間前にこれについて書き、XML は最も広く使用されている表記法の 1 つであるという結論に達しました。
それは最高ですか?私はそうは思いません。私は JSON が本当に好きですが、ツールはまだ XML に対応していないので、様子を見る必要があると思います。
Spring の ClassPathResource を IoC の代替として使用する方法について、簡単なコードを投稿しました。ClassPathResource を使用すると、クラスパス上の任意の場所にプロパティ ファイルを配置できます (たとえば、すべてを 1 つの場所に配置するか、構成するコードのピアとして配置します。私の例では java.util.Properties を使用しているだけなので、プレーンテキストの "name=value" スタイルを使用できます)。またはその XML 形式。
次の URL をご覧ください: http://issues.apache.org/jira/browse/CONFIGURATION-394
私たちが探している構成フレームワークは、Apache Commons 構成の上にあるものであり、同時実行の問題、JMX の問題、およびほとんどのストア (.properties ファイル、.xml ファイル、PreferencesAPI など) をサポートする必要があります。
「管理コンソール」で weblogic チームが提供するものは興味深いものであり、それを介して構成のトランザクション (アトミック) 更新を行い、登録されたリスナーに通知することができます。
Apache 関係者は、このプロジェクトは Commons Configuration の範囲外であると主張しています。
簡単な構成フレームワークを添付しました。見てください。
YamlBeansを試すことができます。このようにして、構成データを保持したいクラスを作成すると、YAML との間でそれらを自動的に読み書きできます。
YAML は人間が判読できるデータ形式です。java.util.Properties よりも表現力があります。リスト、マップ、アンカー、型付きデータなどを持つことができます。
プロパティファイルは非常に単純です。より機能的なものが必要な場合は、構成ファイルの一部をJavaクラスとしてフォーマットできます。これらは別のパッケージ/モジュールに配置でき、BeanShellなどのライブラリを使用して実行時にプリコンパイルまたはロードできます。
注:最も単純なケース(コンパイル済み)では、追加のライブラリは必要ありません。
新しく発表されたtools4j-configを見ることができます。その使命は、実行時に構成を簡単に処理できるようにすることです。
java.util.Properties を使用する提案について - jdk 1.5 以降では、Preferences API (java.util.prefs) が Properties API を使用する代わりに推奨されるようです。
理由: スケーラビリティの向上、バックエンドの中立性など。