Разделите web.xml для разработки и производства

Если вы не можете использовать тот же web.xml во время разработки, Я бы автоматизировал процесс сборки, использовал два web.xml и связал «правильный» во время сборки в зависимости от целевой среды, как предложил Брайан. Но вместо Ant я бы выбрал Maven, потому что он потребует меньше работы ИМХО и имеет встроенную функцию, называемую профили , которая идеально подходит для управления вещами, специфичными для среды, как здесь.

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

Я бы добавил необходимую инфраструктуру, чтобы разрешить механическую сборку с помощью ant или maven.

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

Однако вам следует тщательно рассмотреть возможность тестирования того же кода, что и в производственной среде. Иначе тебя укусят.

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

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

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

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

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

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

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