Блог

Я разработал веб-приложение, которое работает на локальном сервере Apache Tomcat 7.0.14 (моя среда разработки). Я готов отправить свое приложение на рабочий узел, но у меня возникают проблемы с управлением различными значениями ввода для каждой среды.

Мой текущий процесс сборки выполняется полностью в моей среде разработки Netbeans 7.0.1. Он использует Ant, с которым, я признаю, я не знаком, и генерирует файл .war. Я могу выполнить развертывание на своем рабочем хосте, скопировав это .файл войны. Приложение запускается, хотя в нем отсутствуют все правильные данные рабочей конфигурации.

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

Чего я не могу сделать, так это легко поддерживать отдельные значения для моих разных конфигураций. Я надеюсь получить второй экземпляр web.xml или context.xml файл, который я мог бы использовать для создания отдельной копии a .файл войны для развертывания в рабочей среде. Я также был бы доволен решением, которое позволяет мне вставлять какие-то переменные (${}?) в этот файл. Однако я должен иметь возможность сохранять сами данные в файле, потому что там будет большое количество записей. Поскольку данные в любом случае будут храниться в файлах, я подумал, что естественным решением было бы второе web.xml или context.xml досье.

В идеале я хотел бы простое решение в Netbeans. В отсутствие этого, вероятно, будет достаточно инструкций для выполнения этого в Ant. Также была бы полезна любая соответствующая терминология. Я заблудился, читая о «контекстах», «средах» и «развертываниях» в tomcat, которые имеют значения, отличные от того, что я ищу. Наконец, если это невозможно сделать с помощью любого из них, есть ли инструмент, который мог бы помочь? Написание отдельного сценария оболочки было бы далеко от идеала.

Трудно поверить, что для этого нет тривиального решения. Похоже, что это то, что нужно решать при каждом развертывании. Разве не поэтому записи и ссылки существуют в xml? Однако я ничего не смог найти относительно этого в руководстве Tomcat.

У вас есть много вариантов. Для свойств, специфичных для сборки, я бы рекомендовал создавать файлы свойств для каждой среды и загружать их через property задачу в Ant. Так, например, для гипотетических сред dev, qa, prod у вас могут быть файлы свойств с именами build .{env}.properties и загрузите их следующим образом:

build.xml

 <property file="build.${environment}.properties"/>
  

вызывается как:

ant -Denvironment= dev

Это дает вам некоторую полезную замену свойств во время сборки. Но, конечно, вас больше интересует замена переменных в файлах вашего проекта. Один из способов сделать это с помощью задачи Ant Replace . Пример использования:

 <target name="prepare-resources">
    <replace dir="${targetdir}" replacefilterfile="vars.${environment}.properties">
        <include name="**/*.txt"/>
     </replace>
</target>
  

Вы должны вызвать свою сборку Ant, аналогичную первому примеру, который я привел. Вы можете добавить столько типов ресурсов, сколько вам нужно, с помощью дополнительных include директив.

И, наконец, вы также можете выбрать целый набор файлов, помеченных идентификатором среды, и «продвигать» их в нужный артефакт сборки с помощью задачи копирования Ant. Например:

 <target name="promote-resources">
    <copy todir="${targetdir}">
        <fileset dir="${sourcedir}"/>
        <mapper type="regexp" from="(.*).${environment}.(.*)" to="1.2"/>
    </copy>
</target>
  

Вы должны заполнить targetdir и sourcedir по мере необходимости. Приведенный выше фрагмент будет продвигать все файлы типа web.dev.xml или context.dev.xml чтобы web.xml и context.xml .

Вы можете комбинировать все или некоторые из описанных выше методов, чтобы получить настраиваемую сборку, соответствующую вашей среде. Я бы также рекомендовал использовать Maven в качестве инструмента сборки, он значительно упрощает подобные задачи!