Как избежать копирования 40M Java-библиотек в WAR, если размер WAR составляет 41M? - PullRequest
6 голосов
/ 06 апреля 2009

В данный момент мой процесс сборки состоит в переупаковке файла war со всеми необходимыми java-библиотеками в WEB-INF / lib, а затем копировании файла war на сервер разработки / demo / production для повторного развертывания tomcat.

Размер упакованного военного файла составляет около 41 МБ, и на данный момент он имеет около 40 МБ внешних библиотек Java. Там должен быть лучший путь. Как вы решили эту проблему?

Моя машина для разработки представляет собой Windows-коробку с Eclipse в качестве моей IDE и Ant в качестве моего инструмента для сборки. Все серверы - это Linux-боксы с Tomcat 5.5.

Должен ли я добавить файлы jar в пакет war на стороне сервера?

Ответы [ 9 ]

17 голосов
/ 06 апреля 2009

Я понимаю, что вы говорите, и у меня было такое же разочарование в связи с некоторыми нашими веб-приложениями, но для согласованности я бы посоветовал вам оставить все как есть. При копировании библиотек в каталог tomcat / lib вы можете столкнуться с проблемами, связанными с системным classpath или webapp classpath.

Сохраняя вещи такими, какие они есть, вы уверены, что развертываете те же вещи в разработке / демо, что и в производстве. Жизнь - отстой, когда вы вручную настраиваете что-то в работе, или у вас есть какая-то сумасшедшая ошибка, потому что вы забыли обновить XYZ.jar с версии 1.6 до 1.6.1_b33 в работе, и теперь он ведет себя иначе, чем, по вашему мнению, точно такой же код на демо .

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

5 голосов
/ 09 июля 2009

Для этого мы используем инструмент rsync (в нашем случае, используя cygwin под windows) для копирования развертываний на серверы (на которых запущен linux). Мы используем разнесенные файлы WAR / EAR (то есть структуру каталогов с именем MyApp.war, а не zip-файл с именем MyApp.war), rsync будет передавать только файлы, которые были изменены.

В общем случае rsync передает наши взорванные EAR размером 30-40 мегабайт примерно за 5 секунд.

1 голос
/ 04 июля 2009

@ Макдауэлл, упоминая эти серверы J2EE, вы должны уточнить, что они являются серверами J2EE (контейнер сервлетов + остальные).

Как и @digitaljoel, я предлагаю оставить все как есть. Похоже, вы еще не развернули много веб-приложений. Проблемы, которые у вас возникнут, не стоят своей цены (конфликт версий, ошибки развертывания и т. Д.).

1 голос
/ 07 апреля 2009

Tomcat имеет каталог shared / lib , который является подходящим местом для глобальных зависимостей приложений. Однако они будут видны всем приложениям, что повлияет на управление зависимостями и может иметь последствия для таких вещей, как статические переменные. Я не уверен, что вы можете настроить что-нибудь лучше в Tomcat.

Альтернативой является переключение на более сложный веб-контейнер. Например, WebSphere Application Server Community Edition (синяя версия Geronimo ) поддерживает библиотеки для каждого ресурса . Другие бесплатные и коммерческие серверы также поддерживают это. Я знаю WebSphere Application Server , и я почти уверен, что вы можете сделать это в Glassfish .

0 голосов
/ 09 июля 2009

Вам нужен инструмент контроля версий и процесс сборки.

Используйте CSV, SVN, GIT или что-либо еще, что вам нужно, чтобы держать свой источник под контролем. Используйте инструмент сборки для создания приложения: Maven, ant, ...

Теперь, когда вы хотите развернуть свое приложение на своем сервере, вам просто нужно зафиксировать свои обновления на своем компьютере, обновить источник на своем сервере, собрать приложение и развернуть его с сервера.

Таким образом, сервер просто должен будет загрузить ваши модификации, и это должно быть намного быстрее.

0 голосов
/ 04 июля 2009

Я работаю с «взорванным веб-приложением» на серверах разработки, а иногда и на производстве. Процесс развертывания (на основе ANT) обновляет JAR-файлы в WEB-INF / lib с нашими пакетами. Только на сервере разработки мы активируем перезагрузку Tomcat, которая заботится о перезапуске приложения, когда что-то меняется. Вы должны назначить дополнительную постоянную память этим Tomcats и иметь возможность перезапустить сервер, так как перезагрузка может время от времени приводить к аварийному завершению работы Tomcat.

Я знаю, что это странная конфигурация, но я не могу понять, как постоянная перепаковка 30 МБ (и увеличение) нашего типичного приложения могла бы быть лучше. Пусть в один прекрасный день дескриптор разработки разрешит внешние ссылки на библиотеки, которые контейнер может загружать и кэшировать. ??

Извините, мой плохой английский.

0 голосов
/ 07 апреля 2009

Вы можете просто развернуть файл JAR, локально скопировать среду развертывания и просто скопировать измененные файлы и сам файл JAR. Путь является единственной реальной проблемой.

Или вы можете посмотреть, как настроить EAR.

0 голосов
/ 06 апреля 2009

вы можете включить внешние библиотеки Java в каталог Tomcat / lib. Таким образом, они остаются на сервере.

0 голосов
/ 06 апреля 2009

Можете ли вы добавить неизменяемые JAR-файлы в путь к библиотеке Java на стороне сервера и включить в свою WAR-файл только регулярно меняющиеся JAR-файлы?

...