Отдельный web.xml для разработки и производства

Question

Мой web.xml отличается в среде разработки и производства. Например, в среде разработки нет необходимости в ограничениях безопасности.

Обычно я развертываю новую версию приложения следующим образом:

1. Экспорт проекта Eclipse в WAR.
2. Загрузить WAR на сервер.
3. передислоцировать.

Проблема в том, что мне нужно вручную раскомментировать ограничения безопасности в файле web.xml перед экспортом.

Как вы решаете эту проблему?

В некоторых статьях я также встречал мнение, что «web.xml редко изменяется». Но как web.xml не может измениться, если он экспортируется в WAR при каждом обновлении?

Заранее спасибо!

Answer 1

Если вы не можете использовать один и тот же web.xml во время разработки, я бы автоматизировал процесс сборки, использовал два web.xml и связывал «правильный» во время сборки в зависимости от целевой среды, как предложил Брайан. Но вместо Ant я бы выбрал Maven, потому что это потребует меньше работы IMHO, и у него есть встроенная функция под названием profile , которая идеально подходит для управления средой, подобной этой.

Другими словами, я бы поместил сборку под Maven 2 и использовал бы профиль production , содержащий определенную конфигурацию плагина maven-war-plugin, для создания WAR, содержащего web.xml с необходимыми ограничениями безопасности. , Другим вариантом было бы объединить разработку web.xml ( cargo может сделать это), чтобы добавить ограничения безопасности, но это уже немного более «продвинутое» решение (немного более сложное для внедрения) .

Answer 2

Я бы создал развертывание для разработки и производства с разными web.xml конфигами. Автоматизируйте их сборку / обслуживание через вашу сборку (Ant / Maven и т. Д.), Чтобы сохранить контроль над необходимыми общими элементами.

В прошлом мне приходилось много раз решать эту проблему, и в итоге я написал XMLTask - плагин Ant, позволяющий модифицировать XML-файлы без обычной замены текста (это намного умнее) и без необходимости связываться с XSLT (это намного проще). Если вы придерживаетесь вышеуказанного подхода, вы можете проверить это. Вот статья Я написал об этом.

Answer 3

Я считаю, что иметь одну войну, которая работает в разных средах, - лучшее решение, чем выпекать новую войну с опцией профиля для dev, qual и prod. Очень раздражает, что нет лучшего механизма для получения переменных среды непосредственно в web.xml без использования библиотеки, такой как spring.

Одно решение для конфигурации среды web.xml, учитывая, что настройка вашей среды связана с параметрами инициализации фильтра, такими как:

<filter>
    <filter-name>CAS Filter</filter-name>
    <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
    <init-param>
        <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
        <param-value>https://<foo>:8443/login</param-value>
        ...

Конкретный класс фильтра, указанный выше (CASFilter), является открытым. Это означает, что вы можете расширить его с помощью специального адаптера, который добавляется в конфигурацию вашей среды. Это позволяет вам держаться подальше от этого неприятного файла web.xml.

Answer 4

Я бы добавил необходимую инфраструктуру для механической сборки, с муравьями или мавенами.

Когда ЭТО сделано, вы можете сделать так, чтобы ваша механическая сборка создала две цели, одну для тестирования и одну для производства.

Тем не менее, вам настоятельно рекомендуется протестировать тот же код, что и в производстве. В противном случае вас укусят.

Answer 5

Я преобразовал свой проект для сборки, используя ant . Отправной точкой был именно этот build.xml http://tomcat.apache.org/tomcat-6.0-doc/appdev/build.xml.txt

Приведенная выше сборка не имеет функции копирования в другой файл web.xml (на основе, например, набора свойств при сборке), но вы узнаете, как это сделать, когда немного разберетесь в муравье, должно быть довольно легко.

Приятным побочным эффектом является то, что развертывание на удаленном tomcat теперь происходит всего в паре щелчков мышью из Eclipse вместо Export-> war и вручную копируется на сервер.

Answer 6

Предполагая, что вы застряли с идеей web.xml изменить перед развертыванием в производство, тогда мой вероятный подход состоял бы в том, чтобы запустить разработку web.xml с помощью простого XSL-преобразования, которое "украшало" web.xml вашим производственные элементы, такие как ограничения безопасности. Предполагая, что вы можете подключить этот шаг к процессу сборки, в процессе экспорта должен появиться готовый к производству web.xml.

Однако, как правило, не рекомендуется иметь разные web.xml в разных средах, это обесценивает ваше тестирование. Наличие одинакового значения во всех средах снизит риск появления ошибок только в вашей производственной среде.