Это - плохая практика для включения properties/configuaration файлов в банках?
SELECT 'DROP TABLE "' + TABLE_NAME + '"'
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE '[prefix]%'
Это генерирует сценарий.
Добавляющий пункт для проверки существования таблицы перед удалением:
SELECT 'IF OBJECT_ID(''' +TABLE_NAME + ''') IS NOT NULL BEGIN DROP TABLE [' + TABLE_NAME + '] END;'
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE '[prefix]%'
9 ответов
, я бы выбрал D.
Попытайтесь загрузить файлы свойств извне .jar, тогда, если это не удастся , загружать свойства, встроенные в jar.
Это позволяет выдвигать «готовую» конфигурацию с каждой сборкой (также снижает сложность развертывания, если используется всего один файл), а также делает возможным и разумным переопределение конфигураций простой.
D.
Загрузите свойства в jar. Затем создайте новые свойства, используя свойства jar-ed по умолчанию. Затем загрузите снаружи банки. Это позволяет выбрать настройку свойств.
Помните, что в J2EE вам НЕ гарантируется возможность доступа к файлам извне J2EE-среды (без прямого доступа к файлам).
Вам нужно будет использовать JNDI, чтобы указать на источник данных, содержащий ваши данные, или на файл свойств в ваших артефактах развертывания.
Websphere, например, по умолчанию не разрешает прямой доступ к файлам.
Это зависит от обстоятельств. Если файл свойств содержит данные, которые предназначены для изменения пользователем вашего приложения или библиотеки, то он должен находиться вне.
Если он содержит статические данные и вы создали файлы свойств, чтобы избежать кодирования значений в исходный код или, если файлы представляют собой локализованные строки, я бы оставил их в банке. Хотя бы потому, что файл свойств предлагает людям изменить значения;)
Часто это критерий, по которому код должен быть перенесен НЕ ИЗМЕНЕН из тестовой в рабочую. Это означает, что вы не можете редактировать встроенные файлы конфигурации. Также вы можете оказаться в ситуации, когда вам нужно изменить развернутую конфигурацию, что часто бывает очень громоздко. Следовательно, мы оставляем конфигурацию вне jar-файлов.
Для приложений Java EE рассмотрите JNDI или файл свойств в пути к классам.
У меня есть веб-приложение, в котором конфигурация извлекается из соседнего веб-приложения, просто чтобы разделить два . Это оказалось намного проще.
Думаю, ответ зависит от того, считаете ли вы, что вам нужен контроль версий для конфигураций. (Это могут быть рабочие конфигурации или конфигурации для регрессионного тестирования ...)
- Если вам не нужен контроль версий, тогда вариант D с внешним файлом свойств, который переопределяет файл свойств, является хорошим вариантом. Варианты B и C более открыты для дополнений, но если вам действительно интересно, вы бы использовали контроль версий: -)
- Если вам нужен контроль версий, вариант A дает вам больше контроля, но если у вас есть возможность несколько развертываний, вам также может потребоваться / необходимо контролировать версии конфигураций для каждого развертывания. Примером может служить раздельное развертывание для тестовой и производственной платформ.
Вот как мы это делаем, используя модули Maven и «наложения» файлов WAR Maven.
- У нас есть несколько модулей для компонентов кода Java. Это модули JAR.
- У нас есть модуль «base webapp» для статического содержимого, JSP и данных конфигурации ядра (подключение Spring, свойства по умолчанию). Это модуль WAR, поэтому результатом сборки является WAR, который содержит вышеуказанные + все файлы JAR.
- Каждая отдельная «конфигурация сайта» - это модуль WAR, который содержит специфичные для сайта переопределения для свойств, файлов подключения и содержимого. Переопределение описывается с использованием механизма «наложения» Maven WAR и приводит к сборке новой WAR из «базовой» WAR и переопределений.
Все это проверяется в системе контроля версий, и вам необходимо выполнить Maven сборки и развертывания WAR для внесения изменений в конфигурацию.
свойства по умолчанию). Это модуль WAR, поэтому результатом сборки является WAR, который содержит вышеуказанные + все файлы JAR.Все это проверяется в системе контроля версий, и вам необходимо выполнить Maven сборки и развертывания WAR для внесения изменений в конфигурацию.
свойства по умолчанию). Это модуль WAR, поэтому результатом сборки является WAR, который содержит вышеуказанные + все файлы JAR.Все это проверяется в системе контроля версий, и вам необходимо выполнить Maven сборки и развертывания WAR для внесения изменений в конфигурацию.
Я разрабатываю приложения J2EE с использованием Spring. Я довольно долго работал с одной и той же проблемой, а потом нашел решение. Моя проблема заключалась в том, чтобы указать свойства базы данных в файле свойств вне файла war, который я развертываю. Решением, которое я нашел для этого, является использование PropertyPlaceholderConfigurer и указание свойства местоположения для определения местоположения вашей системы следующим образом:
Это было довольно просто и отлично работало!
Я использую файлы свойств в веб-приложениях (WAR), но в основном для значений по умолчанию и прочего более или менее неизменяемого (поскольку веб-приложения не должны обновляться их ВОЙНЫ, даже когда они могут).
За такие вещи, как ты ' Однако я использую JNDI. Вы можете определить свойства как ресурсы в вашем файле web.xml. Таким образом, в худшем случае вы обновляете web.xml, а не само приложение.
Для некоторых серверов есть способы переопределить эти значения ресурсов, вообще не затрагивая WAR. Например, в Tomcat.
я обычно делаю одну WAR для тестирования, Q / A и производства и переопределяю ресурсы, зависимые от среды, именно так, используя файлы Tomcat Context xml. Я считаю, что это намного лучше, чем создавать несколько WAR или изменять WARS, поскольку приложение, которое я тестирую, почти идентично приложению, которое находится в производстве.
Для некоторых серверов есть способы переопределить эти значения ресурсов, вообще не затрагивая WAR. Например, в Tomcat.
я обычно делаю одну WAR для тестирования, Q / A и производства и переопределяю ресурсы, зависимые от среды, именно так, используя файлы Tomcat Context xml. Я считаю, что это намного лучше, чем создавать несколько WAR или изменять WARS, поскольку приложение, которое я тестирую, почти идентично приложению, которое находится в производстве.
Для некоторых серверов есть способы переопределить эти значения ресурсов, вообще не затрагивая WAR. Например, в Tomcat.
я обычно делаю одну WAR для тестирования, Q / A и производства и переопределяю ресурсы, зависимые от среды, именно так, используя файлы Tomcat Context xml. Я считаю, что это намного лучше, чем создавать несколько WAR или изменять WARS, поскольку приложение, которое я тестирую, почти идентично приложению, которое находится в производстве.
Я задавал аналогичный вопрос. Мы еще не во всем разобрались. Но мы изучаем ресурсы URL. Где файл свойств читается прямо из SVN. Не нужно обновлять ничего, кроме файла свойств.