Отслеживание изменений с помощью конфигурации Apache Commons

Для предстоящего проекта я планирую использовать конфигурацию Apache Commons.

Я хотел бы использовать библиотеку для чтения и записи всех конфигураций данного приложения из/в базу данных.

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

Изменения конфигурации происходят не так часто.

Интересно, как лучше всего реализовать эту функцию отслеживания изменений? Есть ли поддержка в самом Apache Commons? Есть ли другой подходящий фреймворк/библиотека?


java configuration apache change-tracking apache-commons-config
person jbandi    schedule 27.12.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

К сожалению, я не думаю, что существует какое-либо совпадение между конфигурацией Apache Commons и вашим требованием к базе данных конфигурации отслеживания изменений.

Если вам нужно хранить конфигурации в базе данных, я подозреваю, что вам понадобится либо другая структура, либо собственное решение. Ре. база данных, 2 мысли:

  1. вы можете хранить конфигурации с датой начала/действия. Текущая конфигурация будет иметь нулевую дату действия, и вы должны установить дату действия при обновлении конфигурации.
  2. некоторые базы данных поддерживают понятие версионных данных. Например. В Oracle есть функция flashback, с помощью которой вы просто повторно запишите объект базы данных, а Oracle запишет версию этой таблицы в то время (особенности, вероятно, намного сложнее). Это может быть полезным решением, если вам просто нужна история изменений конфигурации для целей аудита.

Другим решением является управление вашими конфигурациями с помощью SCM и упаковка/развертывание таких конфигураций с выпусками. например создайте конфигурации dev/test/prod в репозитории исходного кода и управляйте изменениями там. Оберните эти конфигурации в своем развертываемом и выпустите в соответствующие среды. У вас есть возможность отслеживания изменений SCM, но вы не можете легко отслеживать изменения, происходящие в развернутой среде. Ваши процессы управления изменениями могут/не позволяют этого.

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

person Brian Agnew    schedule 27.12.2012
comment
Спасибо за этот ответ. Вы упоминаете другую структуру... знаете ли вы ту, которая соответствует требованиям? Классический SCM в нашем случае не подойдет, т.к. конфигурации меняются в продакшене пользователями приложения. Однако может быть полезен какой-то встраиваемый SCM, который можно использовать в качестве библиотеки в приложении Java... однако я не знаю такого SCM... - person jbandi; 28.12.2012
comment
Если вы можете быть уверены, что SCM будет доступен на всех развернутых машинах, вы можете использовать java.lang.Runtime.exec() для выполнения команд SCM из вашего Java-приложения. Да, при создании процесса будут накладные расходы, но, поскольку вы говорите, что изменения конфигурации происходят нечасто, я не думаю, что накладные расходы будут проблемой. - person Ciaran McHale; 30.12.2012
comment
@Ciaran Спасибо, но нет, SCM не будет доступен на развернутой машине, и я также не могу и не хочу иметь его в качестве внешней зависимости. Я скорее думал о встраиваемом SCM в том смысле, что весь SCM является частью моего приложения... что-то вроде GIT в виде библиотеки... которая предоставляет API для приложения и записывает в какой-то локальный (файловый) ) репозиторий. - person jbandi; 07.01.2013
comment
Отвечаю себе: JGit действительно хорошо соответствует моему представлению о Git как о библиотеке: eclipse.org/jgit ... - person jbandi; 08.01.2013