Что лучший способ состоит в том, чтобы управлять данными конфигурации

Вы почти у цели ... Я хотел бы придерживаться того же подхода и вытащить правильный файл конфигурации для экземпляра приложения, которое выполняется методом, аналогичным одному из следующих:

1. Назовите все ваши файлы конфигурации по-разному, и ваше приложение получит их по некоторым уникальным критериям (имя пользователя, имя хоста и т. Д.):

   • production .properties
   • developer1 .properties
   • developer2 .properties

2. Держать их вне кодовой базы в местоположении, основанном на переменной среды, которая, как предполагает приложение, существует:

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

Я даже использовал комбинацию этих подходов в одном и том же проекте (# 1 для конфигураций процесса сборки и # 2 для конфигураций во время выполнения).

Для всех наших сред данные конфигурации хранятся на целевых машинах в форме файлов свойств. Мы используем PropertyPlaceholderconfigurer из SpringFramework, чтобы связать эти свойства с нашими приложениями, чтобы обеспечить переносимость между средами.

Например, если я знаю, что /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"

Или просто та же опция -D, переданная при вызове «java», в зависимости от того, что вы делаете.

Кстати, мы храним наши файлы свойств отдельно как RPM.

Переменные окружения - это самый простой способ. Установите их так же, как и в любое другое время, получите к ним доступ с System.getenv("...")

Вот простое глупое решение.

Фрагмент кода, который сначала пытается использовать файл свойств в текущем каталоге. В случае неудачи используйте файл свойств в каталоге ресурсов (или в файле jar).

    Properties configFile = new Properties();
    try {
        configFile.load(new FileInputStream("production.properties"));
    } catch (Exception e) {
        System.err.println("Can not read properties, try to use default properties file.");
        configFile.load(this.getClass().getClassLoader().
                    getResourceAsStream("development.properties"));
    }

Если ваши приложения работают с базой данных, вы можете создать таблицу «конфигурации» следующим образом:

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

Вы должны инициализировать ее с помощью сценария инициализации, скажем init.sql с содержимым в строках:

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

Преимущества этого подхода заключаются в следующем:

• вы создаете версию скрипта вместе с вашим кодом
• , вы можете легко расширить его, включив {{ 1}} для отдельных пользователей или групп, добавив идентификатор пользователя / группы
• , вы можете изменить настройки во время выполнения , если вам это нужно
• , вы можете используйте тот же стек (JPA + DAO, Cayenne ...), который вы обычно используете для обработки основных данных приложения, чтобы обрабатывать данные конфигурации

Используя 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");