Я могу использовать единственный военный файл в нескольких средах? Должен я?
Я думаю принцип DRY (не Повторяйте Себя), объединенный с немного Гибким хороший подход. Создайте свою программу, инкрементно запускающуюся с самой простой вещи, которая работает, затем добавляют опции один за другим и осуществляют рефакторинг Ваш код по мере необходимости, как Вы продвигаетесь.
, Если Вы пишете те же немного строк кода снова и снова - возможно, с различными данными - пора думать об абстракциях, которые могут помочь разделить материал, который изменяется от материала, который остается таким же.
Создают полные модульные тесты на каждое повторение так, чтобы можно было осуществить рефакторинг с уверенностью.
Это - ошибка провести слишком много времени, пытаясь ожидать, какие части Вашего кода должны быть допускающими повторное использование. Это скоро станет очевидным, после того как система начинает увеличиваться в размере.
Для больших проектов с несколькими параллельными группами разработчиков у Вас должен быть некоторый архитектурный план вести разработку, но если Вы работаете самостоятельно, или в малочисленной совместной команде затем архитектура появится естественно, если Вы будете придерживаться принципа DRY.
Другое преимущество этого подхода состоит в том, что независимо от того, что Вы делаете, основан на опыте реального мира. Моя любимая аналогия - необходимо играть с кирпичами, прежде чем можно будет вообразить, как здание могло бы быть создано.
7 ответов
Это действительно зависит от того, для чего вы используете эти свойства.
Некоторые (например, источник данных) можно настроить в самом контейнере ( Tomcat 5.5. Ресурсы JNDI , см. Также раздел источников JDBC).
Другие (зависящие от приложения) могут действительно быть свойствами. В этом случае ваш выбор:
- Объединить свойства в WAR-файл и загрузить соответствующее подмножество на основе некоторого внешнего переключателя (либо переменной среды, либо свойства JVM).
- Настройте процесс развертывания на каждом из ваших серверов, где распаковывается война и файл свойств (расположенный в заранее определенном месте на этом сервере и относящийся к этому серверу) копируется в
WEB-INF / classes(или другое подходящее место).
Насколько "это желаемая цель "идет - да, я так думаю. Наличие одной WAR для тестирования в QA / staging и последующего развертывания в производственной среде исключает промежуточный этап и, таким образом, оставляет меньше шансов для ошибок.
Обновление (на основе комментария):
Пункт № 1 выше относится к фактическая переменная среды (например, то, что вы установили с помощью SET ENV_NAME = QA в Windows или ENV_NAME = QA; экспорт ENV_NAME в Linux). Вы можете прочитать его значение из своего кода, используя System.getenv () , и загрузить соответствующий файл свойств:
String targetEnvironment = System.getenv("TARGET_ENV");
String resourceFileName = "/WEB-INF/configuration-" + targetEnvironment + ".properties";
InputStream is = getServletContext().getResourceAsStream(resourceFileName);
Properties configuration = new Properties();
configuration.load(is);
Но да, вместо этого вы можете определить скалярное значение через JNDI ( см. Записи среды в Tomcat doc ) вместо:
<Context ...>
<Environment name="TARGET_ENV" value="DEV" type="java.lang.String" override="false"/>
</Context>
и прочтите его в своем приложении через
Context context = (Context) InitialContext().lookup("java:comp/env");
String targetEnvironment = (String) context.lookup("TARGET_ENV");
// the rest is the same as above
Дело в том, что если вы все равно будете использовать JNDI, вы можете отказаться от файлов свойств и настроить все через JNDI. Источники данных будут доступны вам как фактические ресурсы, а основные свойства останутся скалярами (хотя они будут безопасными по типу).
В конечном итоге вам решать, какой способ лучше подходит для ваших конкретных нужд; у обоих есть свои плюсы и минусы.
Задайте системное свойство при запуске, которое указывает на расположение вашего файла свойств, а затем в приложении извлеките это свойство и загрузите свои настройки. Еще у меня есть два файла свойств, что-то вроде default.properties и external.properties. Они содержат те же свойства, но default.properties содержит значения по умолчанию (работает большую часть времени), этот файл идет на войну. Затем, если вы развернете в env. вы ищете external.properties, если обнаружите, что он используется, если нет, то вы откатываетесь к default.properties. Это дает хороший способ переопределить свойства, если это необходимо, но также имеет настройку по умолчанию. Это работает во многих моих развертываниях, но может не работать в вашем сценарии.
Я думаю, что одиночный файл war - хороший вариант, потому что приятно быть уверенным, что двоичный файл, который вы тестировали в DEV, точно такой же, как и в Production. Как мы это делаем, мы сохраняем конфигурации в отдельном файле свойств, вне войны, но в пути к классам сервера приложений.
Если вы хотите сохранить все свойства внутри войны (что действительно упрощает развертывание, потому что тогда вам не нужно также развертывать файл свойств), вы можете сохранить один файл свойств в пути к классам, который определяет тип среды сервера, и использовать его для ключевых значений в файле свойств в вашем .war файле. Файл внешних свойств также может быть хорошим вариантом для некоторых высокоуровневых конфигураций, которые не сильно меняются и используются во многих файлах войны.
Вероятно, самым простым способом было бы установить переменную среды, которая различается между службами приложения, и использовать ее для определения файла свойств для чтения.
Другой возможностью было бы сохранить свойства в базе данных и использовать источник данных, который существует под стандартным именем JNDI, но указывает на другое место в различных средах.
Я предпочитаю один EAR или один подход WAR. Есть кое-что обнадеживающее и часто требуемое с точки зрения безопасности в том, чтобы взять тот же самый EAR, который только что был протестирован, и переместить его непосредственно в следующее состояние (тест> Производство).
Кроме файлов свойств, предоставляемых контейнером, есть также много параметров. Часто контейнер имеет приятный пользовательский интерфейс для поддержания этих значений и ресурсов, когда вы мертвы и ушли.
Существует бесчисленное множество примеров использования базы данных ResourceBundle .
Например, в среде Spring есть несколько механизмов, позволяющих сделать это без особых усилий. Начиная с PropertyPlaceholderConfigurer
Абсолютно одна WAR - это лучший способ пойти. Задайте для ресурсов одинаковые имена JNDI в каждой среде, и если вам нужно определить, в какой среде вы находитесь, для целей бизнес-логики, используйте свойство System при запуске Tomcat.
То, что вы делаете, это несчастный случай, ожидающий своего часа ... Однажды война DEV закончится на сервере de PROD, и по какому-то закону, превосходящему все законы природы, эта проблема будет обнаружена в 2 часа ночи. Не могу объяснить, почему это так, но когда-нибудь это произойдет. Так что одна война, на мой взгляд, определенно хорошая идея.
Вы можете установить системное свойство в соответствующей JVM (-Dcom.yourdomain.configpath = / where / you / store / configfiles) и получить это свойство с помощью
String value = System.getProperty("com.yourdomain.configpath", "defaultvalue_if_any");
Значение по умолчанию может указывать где-то внутри войны (WEB-INF / ...), или, если по умолчанию нет, использоваться для создания некоторого шума при регистрации во время загрузки для предупреждения о неправильной конфигурации). Также обратите внимание, что этот метод не зависит от платформы, поэтому вы можете использовать машину для разработки с Windows, а сервером с Linux, она может справиться с обоими. Обычно мы создаем подкаталог для каждого приложения в этом пути конфигурации, так как несколько приложений используют эту систему на сервере, и мы хотим, чтобы все было в порядке.
В качестве дополнительного бонуса вы не рискуете выбросить вручную настроенные файлы свойств на PROD сервер таким образом. Только не забудьте указать путь, по которому файлы хранятся в сценарии резервного копирования.