Загрузка свойств из разных мест

Question

Я борюсь за решение для доступа к файлам конфигурации из разных мест в зависимости от разных условий (dev, prod).

Вот приблизительная схема моего проекта.

│ pom.xml 
    └───src 
     └───main 
      ├───java 
      │  ConfigurationLoader.java 
      ├───resources 
      │  conf1.properties 
      └───webapp 
       │ web.xml 
       └───WEB-INF 

ConfigurationLoader является самоописанным классом и должен быть каким-то обычный синглтоном, статический доступен по всему приложению.

В dev среде он должен загрузить conf1.properties от корня пути к классам, но в prod окр он должен найти их в корневой папке контейнера (напр. %TOMCAT_HOME%\bin).

Как правильно использовать ConfigurationLoader для загрузки таких выборочных свойств?

Благодаря

UPD:

Я больше заинтересован в ConfigurationLoader реализации и файлы свойств местах. Проблема заключается в том, как ConfigurationLoader найти эти файлы. Что-то вроде:

String path = "/conf1.properties"; 
File confFile; 
switch (environment) { 
    case "dev": //classpath 
    URI location = ConfigurationLoader.class.getResource(path).toURI(); 
    confFile = new File(location); 
    break; 
    case "prod": //root (?) 
    confFile = new File(path); 
    break; 
} 
Properties p = new Properties(confFile); 

Здесь приходит несколько вопросов:

1. Как я должен передать переменные окружения в код из Maven (определенный в профилях или любой другой)? Я не хочу фильтровать java-классы и, возможно, предварительно загружать другой файл свойства только с записью среды. Кроме того, я не думаю, что смогу изменить системные свойства (-Denv=whatever) на производственной платформе.

2. Что делать, если файл свойства должны содержать пути для некоторых ресурсов, которые будут доступны для других компонентов системы (напр. applicationContext.xml для пружины, которая также должна быть на любом пути к классам для dev или в папке этого bin TOMCAT в)? Как должны выглядеть эти пути и как они будут нуждаться в их решении в моем коде, избегая дублирования кода этого раздела ConfigurationLoader?

Есть ли шанс разрешить его больше в maven и меньше в коде или какие другие подходы существуют?

Answer 1

Хотя есть problably множество решений, я предпочел бы следующие:

Использование двух различных классов, которые реализуют один и тот же интерфейс (например, интерфейс ConfigurationLoader), тот, который будет обрабатывать конфигурацию из пути к классам и один, который будет обрабатывать файл случае. Используйте файл свойств для вашего приложения (например, app.properties), который будет создан вашей сборкой (разные значения для prod и dev) и всегда будет находиться в одном месте в пути класса, например. корневой пакет.В этом файле вы будете иметь следующие свойства:

config.loader.class=com.mycompany.ClasspathConfigurationLoader # or FileConfigurationLoader for prod environment 
config.loader.resource.classpath=resources/conf1.properties # use classloader.getResourceAsStream() to load this resource 
config.loader.resource.file=/path/to/tomcat/home/bin/conf1.properties 

Теперь, так как ваш загрузчик одноэлементно вы бы иметь статический блок, который будет читать файл свойств и на основе первого свойства было бы решить, какой тип инстанции создайте как класс ConfigurationLoader. Каждый экземпляр экземпляра может затем использовать дополнительные свойства, чтобы решить, какой ресурс нужно загрузить.

Answer 2

Возлюбите вопрос! У нас была такая же проблема, и она была решена следующим образом. Структура нашего проекта в основном такая же, за дополнительную external-resources-{username} папку, кроме:

│ pom.xml 
    └───src 
     └───main 
      ├───java 
      │  ConfigurationLoader.java 
      ├───external-resources-drvdijk 
      │  conf.properties 
      ├───resources 
      │  conf.default.properties 
      └───webapp 
       │ web.xml 
       └───WEB-INF 

Затем в pom.xml, мы включили:

<profiles> 
    <profile> 
     <id>development</id> 
     <build> 
      <resources> 
       <resource> 
        <directory>src/main/external-resources-${user.name}</directory> 
        <filtering>true</filtering> 
       </resource> 
      </resources> 
     </build> 
    </profile> 
</profiles> 

Это позволяет каждому члену команды, чтобы создать свой собственный external-resources-{username} каталог, включающий профиль Maven и здание.

Наша версия ConfigurationLoader.java (на самом деле называется по-разному в нашем проекте) сначала прочитать все свойства из conf.default.properties файла (они также могут быть «пустыми» свойствами, например db.username =). Затем он загрузит conf.properties, включенный в профиль Maven, или в каталог lib сервера приложений, и перезапишет все существующие свойства, найденные в conf.default.properies, с теми, что найдены в conf.properties.

В нашем conf.default.properties мы в явном виде перечислены все свойства, которые может обрабатывать наше приложение. Если после загрузки всех свойств (включая conf.properties) некоторые из них отсутствуют (или найдены некоторые неизвестные), приложение вызвало бы много ошибок и отказалось бы запускать.

Надеется, что это помогает :)