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

Например:

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, чтобы определить местоположение вашей системы как это,

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