Подтвердить что ты не робот

Конфигурация веб-приложений вне или внутри файла войны?

В веб-приложении обычно есть как минимум один файл конфигурации, содержащий конфигурацию jdbc и другие настройки. Вы можете поместить такой файл (-s) в файл .war или вне его. Каковы минусы и плюсы этих подходов? Каков ваш подход и почему?

4b9b3361

Ответ 1

Imho, снаружи кажется наиболее удобным, если вам нужно развернуть ту же войну в разных средах. Например, dev, itt, uat и production. То же самое постройте разные конфигурации.

Ответ 2

По моему мнению, значение параметра приложения никогда не должно быть объединено с двоичным. Они должны быть помещены в отдельный файл или базу данных. Это основная передовая практика. Вы никогда не знаете, когда вам или кому-то еще нужно будет отрегулировать один из параметров - и вы можете не быть рядом - или исходный код может быть недоступен.

Ответ 3

IMHO лучший способ - использовать гибкий подход и позволить config быть внутри и/или вне WAR (с некоторой дополнительной логикой для порядка поиска в config и именами файлов /dir, которые могут быть сохранены в конфигурации).

У меня есть опыт работы с чрезвычайно разными моделями/схемами развертывания - иногда это одна сборка/множество конфигураций, в другое время - даже: многие сборки/одна конфигурация на одном сервере - странная, но может случиться; -).

Это может быть особенно полезно, если вы разрабатываете какую-то платформу, которую ваши клиенты/пользователи могут развертывать в пользовательских средах, не указанных в времени сборки WAR.

Ответ 4

Поместите их в войну и используйте какие-то профили сборки (например, maven build profiles). Таким образом:

  • У вас есть одноэтапное развертывание. Не ручное редактирование свойств в удаленных средах.
  • у вас могут быть разные артефакты (военные файлы) для разных сред, поэтому сборка по-прежнему переносима, но вам не нужно открывать войны с программным обеспечением ZIP для изменения настроек.

Способ реализации/использования профилей сборки зависит от вашей среды сборки.