Это плохая практика включать файлы свойств / конфигурации в jar-файлы? - PullRequest
21 голосов
/ 30 июля 2009

Например:

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

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

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

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

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

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

D. Другое:

Спасибо!

Ответы [ 11 ]

0 голосов
/ 31 июля 2009

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

...