Неправильная ли практика включать файлы свойств/конфигураций в банках?

Например:

MyApp - это веб-приложение, содержащее файл свойств (server.properties), который описывает конфигурационные данные (например, имена серверов) для приложения. На этапе разработки server.properties находится в своей собственной папке проекта IDE (логическое место для нее).

Теперь пришло время развернуть MyApp. IDE делает довольно тривиальным создание файлов классов, а также поддерживающих файлов конфигурации. Теперь мы просто бросаем Jar в соответствующий веб-контейнер и уходим...

Через неделю... данные конфигурации сервера, которые MyApp использует, необходимо изменить. Что имеет смысл?

а. Измените файл server.properties на земле IDE и создайте совершенно новый файл jar. Переустановка. (что означает отскакивание приложения для простого изменения конфигурации).

В. Crack открыть уже развернутый Jar и изменить файл server.properties? (возможно, придется вызвать функцию обновления в MyApp, если server.properties кэшируется... но не требует полного отскока приложения. Также необходимо помнить об изменении исходных server.properties, так что будущие развертывания не возвращают server.properties к старым именам серверов).

С. Сделать server.properties внешним по отношению к файлу jar в первую очередь. Очень похож на процесс B, с незначительной разницей в сохранении данных конфигурации, внешних по отношению к банке (вводит разные пути между развертыванием разработки и производством)

Д. Другое:

Спасибо!

Ответы

Ответ 1

Я бы пошел с D.

Попробуйте загрузить файлы свойств из-за .jar, а затем, если это не удается, загрузите свойства, встроенные в банку.

Это позволяет выталкивать "готовую" конфигурацию с каждой сборкой (также уменьшает сложность развертывания, если только одним файлом), а также делает переопределяющие конфигурации возможными и достаточно простыми.

Ответ 2

Если вы используете Spring, вы можете использовать заполнитель свойств для выполнения работы.

<!-- try and resolve the config from the filesystem first and then fallback to the classpath -->
<context:property-placeholder location="file:config.properties, classpath:config.properties"
                              ignore-resource-not-found="true"/>

Вы можете указать ресурс в файловой системе, а также в пути к классам, Spring сначала попробует и устранит все свойства из файловой системы, а затем вернется в путь к классам. Указав атрибут "игнорировать-ресурс-не-найденный" как "истинный", он предотвратит исключение Spring исключения, если файл отсутствует в файловой системе и разрешить ему вместо этого разрешать свойства из пути к классам.

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

В папке, содержащей:

application.jar
config.properties

Вы должны иметь возможность использовать:

java -jar application.jar

Это пример config.properties для справки:

# This file contains properties that are used to configure the application
database.url=127.0.0.1
database.port=3306
database.user=root
database.pass=p4ssw0rd

Ответ 3

Это зависит. Если файл свойств содержит данные, которые должны быть изменены пользователем вашего приложения или библиотеки, то он должен находиться снаружи.

Если он содержит статические данные и вы создали файлы свойств, чтобы избежать кодирования значений в исходном коде или если файлы являются локализованными строками, я оставил их в банке. По крайней мере, потому что файл свойств приглашает людей изменять значения;)

Ответ 4

Д.

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

Ответ 5

Помните, что в J2EE вы не можете получить доступ к файлам вне среды J2EE (без прямого доступа к файлам).

Вам нужно будет использовать JNDI, чтобы указать на источник данных, содержащий ваши данные, или файл свойств в артефактах развертывания.

Websphere, например, не разрешает прямой доступ к файлам по умолчанию.

Ответ 6

Часто это критерий, по которому код должен быть перенесен с НЕПРЕРЫВНЫМ из теста в производство. Это означает, что вы не можете редактировать встроенные файлы конфигурации. Также вы можете остановиться в ситуации, когда вам нужно изменить развернутую конфигурацию, которая часто очень громоздка. Следовательно, мы оставляем конфигурацию вне банок.

Для приложений Java EE рассмотрим JNDI или файл свойств в пути к классам.

У меня есть веб-приложение, в котором конфигурация удаляется из соседнего веб-приложения просто для разделения двух. Это оказалось намного проще.

Ответ 7

Вариант D. В разных средах вам может потребоваться указать, нужно ли указывать свойства среды, такие как подключение к базе данных или прокси и т.д.

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

например. Сервер базы данных упал, и вам нужно указать другой сервер (если не использовать балансировщик баз данных). Итак, все, что вам нужно сделать, это заменить свойства базы данных и перезапустить. Вы сохраняете там много времени.

Ответ 8

Я использую файлы свойств в webapps (WARs), но в основном для значений по умолчанию и вещей, которые более или менее неизменяемы (поскольку webapps не должен обновлять свои WAR, даже когда они могут).

Для таких вещей, как то, о чем вы говорите, я использую JNDI. Свойства можно определить как ресурсы в файле web.xml. Таким образом, в худшем случае вы обновляете web.xml, а не само приложение.

Для некоторых серверов есть способы переопределить эти значения ресурсов, не касаясь WAR вообще. Например, в Tomcat.

Я обычно делаю одну WAR для тестирования, Q/A и производства и переопределяю ресурсы, чувствительные к среде, именно так, используя файлы Tomcat Context xml. Я считаю это намного лучше, чем создавать несколько WAR или изменять WARS, так как приложение, которое я тестирую, почти идентично приложению, которое в процессе производства.

Ответ 9

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

  • Если вам не нужен контроль версий, тогда вариант D с внешним файлом свойств, который переопределяет файл свойств, является хорошим. Опции B и C более открыты для наполнения, но если вы действительно заботитесь о том, что используете контроль версий: -)
  • Если вам нужен контроль версий, опция A дает вам больше контроля, но если у вас есть возможность нескольких развертываний, вам также может понадобиться/нужно управлять версиями конфигураций для каждого развертывания. Примером может служить отдельное развертывание на тестовых и производственных платформах.

Вот как мы это делаем, используя модули Maven и Maven WAR "наложения".

  • У нас есть несколько модулей для компонентов кода Java. Это JAR-модули.
  • У нас есть модуль "base webapp" для статического содержимого, JSP и данных конфигурации ядра (проводка Spring, свойства по умолчанию). Это модуль WAR, поэтому результатом построения является WAR, который содержит все вышеперечисленные файлы JAR.
  • Каждая отдельная "конфигурация сайта" - это WAR-модуль, который содержит переопределения для свойств свойств, файлов подключений и контента. Переопределение описывается с использованием механизма Maven WAR "overlay" и приводит к тому, что новая WAR собирается из "базовой" WAR и переопределений.

Все это проверяется на управление версиями, и вам нужно выполнить развертывание Maven и WAR, чтобы внести изменения в конфигурацию.

Ответ 10

Я задал аналогичный вопрос. Мы все еще не поняли. Но мы изучаем Ресурсы URL. Если файл свойств считывается непосредственно из SVN. Не нужно ничего обновлять, кроме файла свойств.

Ответ 11

Я разрабатываю приложения J2EE с помощью Spring. Я довольно долго бегал по той же проблеме, а затем нашел решение.  Моя проблема заключалась в том, чтобы указать свойства базы данных в файле свойств за пределами военного файла, который я развертываю. Решение, которое я нашел, это использовать PropertyPlaceholderConfigurer и указать свойство location, чтобы определить местоположение вашей системы как это,

  

Это было довольно просто, и все получилось просто отлично!