30

私は4つの製品を持つ製品スイートに取り組んでいます。現在、すべての構成データはXMLファイルまたはプロパティファイルのいずれかにあります。このアプローチは、環境（本番、開発など）ごとに異なる構成ファイルを管理する必要があるため、維持できません。

では、構成データを処理するための最良の方法は何ですか？

また、これを別のモジュールにモジュール化できますか？すべての製品がこのモジュールを使用できるようにします。プロパティファイルは使いたくありません。すべての構成固有のコードを新しい構成モジュールとして移動し、すべての構成データをデータベースに保持できるソリューションを探しています。

4

7 に答える 7

21

commons-configurationを使用すると、プロパティがどのように表現されているかに関係なく、プロパティにアクセスするための統合APIが得られます（.properties、xml、JNDIなど）。例：

config.properties：

jdbcHost=192.168.12.35
jdbcUsername=dbuser
jdbcPassword=pass

config.xml：

<config>
   <jdbcHost>192.168.12.35</jdbcHost>
   <jdbcUsername>dbuser</jdbcUsername>
   <jdbcPassword>pass</jdbcPassword>
</config>

どちらの場合も、次のような方法でアクセスできます。

String host = config.getString("jdbcHost");
于 2010-02-24T06:37:39.520 に答える
12

もうすぐです...同じアプローチを維持し、次のいずれかの方法で実行されているアプリケーションのインスタンスの正しい構成ファイルを取得します。

  1. すべての構成ファイルに異なる名前を付け、アプリケーションにいくつかの固有の基準（ユーザー名、ホスト名など）でそれらをプルさせます。

    • プロダクション.properties
    • developer1 .properties
    • developer2 .properties

  2. それらをコードベースの外の、アプリケーションが存在すると想定する環境変数に基づく場所に保持します。

    • YOURAPP_CONFIG_DIR /server_config.xml
    • YOURAPP_CONFIG_DIR /database_config.properties

同じプロジェクトでこれらのアプローチを組み合わせて使用​​したこともあります（ビルドプロセス構成の場合は＃1、ランタイム構成の場合は＃2）。

于 2010-02-24T06:37:58.460 に答える
5

アプリケーションがデータベースで動作する場合、次のように「構成」テーブルを作成できます。

create table configuration (mode char(3), key varchar(255), value varchar(1023));

次の行に沿った内容を持つ init.sql などの init スクリプトを使用して初期化します。

insert into configuration values ('pro', 'param1', 'value1'); -- production
insert into configuration values ('dev', 'param1', 'value1'); -- development
insert into configuration values ('tst', 'param1', 'value1'); -- testing
...

このアプローチの利点は次のとおりです。

  • コードと一緒にスクリプトをバージョン管理する
  • ユーザー/グループIDを追加することで、ユーザーごとまたはグループごとの設定を含めるように簡単に拡張できます
  • 必要に応じて実行時に設定を変更できます
  • 通常、コアアプリケーションデータを処理して構成データを処理するために使用するのと同じスタック（JPA + DAO、Cayenne ...）を使用できます
于 2010-02-24T11:22:42.173 に答える
4

すべての環境で、構成データはターゲット マシン上にプロパティ ファイルの形式で存在します。SpringFramework のPropertyPlaceholderconfigurerを使用してこれらのプロパティをアプリにバインドし、環境間での移植性を維持します。

たとえば、アプリが実行されるマシンに /etc/myapp/database.properties が存在することがわかっている限り、私の春の構成では、次のようなものが必要です。

    <bean id="myPropertyConfigurer"
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <value>/etc/myapp/database.properties</value>
        </list>
    </property>
</bean>
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url"
        value="jdbc:mysql://${db.host}:3306/${db.name}" />
    <property name="username" value="${db.user}" />
    <property name="password" value="${db.pass}" />     
</bean>

そのSpringクラスには、プロパティファイルが存在できる場所に関する多くのオプションがあります。それらを置換して、環境変数として渡すこともできます。

    <bean id="myPropertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="searchSystemEnvironment" value="true" />
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
    <property name="locations">
        <list>
            <value>${database.configuration.file.url}</value>
        </list>
    </property>
</bean>

そして bash_profile (または何でも): export JAVA_OPTS="-Ddatabase.configuration.file.url=file:///etc/myapp/database.properties"

または、実行している内容に応じて、「java」を呼び出すときに同じ -D オプションを渡します。

FWIW、私たちはプロパティ ファイルを RPM として個別に管理しています。

于 2010-02-24T09:00:16.573 に答える
2

さまざまな戦略がたくさんあります。それらはすべて優れており、あなたに最も適したものに依存します.

  1. 単一のアーティファクトを構築し、構成を別の場所にデプロイします。アーティファクトにはプレースホルダー変数を含めることができ、展開時に構成を読み込むことができます。Springs プロパティのプレースホルダーを見てください。これは、Spring を使用する Web アプリケーションで素晴らしく機能し、ops を関与させる必要はありません。
  2. Web アプリケーションの外部にある、外部化されたプロパティ構成を用意します。場所を一定に保ち、常にプロパティ構成から読み取ります。任意の段階で構成を更新すると、再起動すると新しい値になります。
  3. 環境を変更する場合 (アプリケーション サーバーの使用やユーザー/グループのアクセス許可など) は、上記の方法を puppet またはchef で使用することを検討してください。また、これらのツールを使用して構成ファイルを管理することも検討してください。
于 2012-04-24T01:31:29.660 に答える