Развертывание Spring-WAR с его JAR-зависимостями

Question

У меня есть приложение Spring, которое имеет много зависимостей (18 мегабайт файлов JAR ..) - Теперь, когда я тестирую на удаленном сервере Tomcat 6.0, мне не нужно загружать эти 19 мегабайт зависимости, и просто загрузить классы. Довольно просто, верно?

Я не могу заставить эту чертову штуку работать.

Я использую Eclipse 3.4, и если в Java Build Path-> Order and Export я удаляю экспорт всех зависимостей, я получаю небольшую маленькую WAR.

Итак, вот что я попробовал:

Я загрузил все библиотеки на сервер и вставил их в общую / lib в Tomcat. Каталог не существует, поэтому я создал его и изменил catalina.properties:

shared.loader=${catalina.home}/common/lib/*.jar

Я пробовал кучу других конфигов, но ни один не работал. Перезагрузите сервер, развернутая война не запускается. В частности:

SEVERE: Error configuring application listener of class org.springframework.web.context.ContextLoaderList$java.lang.ClassNotFoundException:org.springframework.web.context.ContextLoaderListener       at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1

Умирает при попытке загрузить прослушиватель Log4J, которого он не может найти в своем пути к классам. Spring lib, в котором находится слушатель, находится в общем / lib.

Кроме того - когда я развернул всю войну 18 мегабайт, все работает просто отлично. Все начинается, и приложение запускается. Конечно, он хорошо работает и локально.

О - и я заменил жестко закодированные JAR-файлы журналов на файлы из папки extras, чтобы позволить Log4j работать.

Любая помощь здесь? Я понятия не имею, почему это не работает.

Answer 1

"У меня есть приложение Spring, которое имеет много зависимостей (18 мегабайт файлов JAR ..) - Теперь, когда я тестирую на удаленном сервере Tomcat 6.0, мне не нужно загружать эти 19 мегабайт зависимостей, и просто загрузите классы. Довольно просто, верно? "

Я не понимаю этого - 19МБ это не много. Тебе было бы гораздо лучше просто упаковать ВОЙНУ и покончить с этим.

Я рекомендую вам провести локальное тестирование на своем идентичном экземпляре Tomcat, заставить его все работать, а затем развернуть WAR на удаленном экземпляре Tomcat.

ОБНОВЛЕНИЕ. Одна из проблем, с которыми я столкнулся при помещении этих JAR-файлов в каталог / lib Tomcat, заключается в том, что теперь каждое приложение, которое вы развертываете в этом экземпляре, видит эти JAR-файлы - измените их на один, все они затронуты. Если вы поместите JAR-файлы в каждый отдельный WEB-INF / lib, вы можете изменить каждое приложение, не затрагивая другие. Стоимость - это дубликаты JAR и дисковое пространство, что дешево.

Еще одна проблема, если вам нужно перейти с devl-> test-> prod, теперь для того, чтобы ваше приложение работало, в каждой среде должны быть развернуты идентичные JAR-файлы. Мисс один, и ты сломан. Ваше приложение зависит от наличия этих зависимостей. Если их нет на сервере, вам не повезло. Держите контроль в своих руках и упакуйте файлы JAR в файл WAR.

Answer 2

Я предлагаю отправить обновления прямо в $ {CATALINA_HOME} / webapps / на целевом сервере. WAR-ы предназначены для производственного развертывания, но если у вас медленное соединение и большая WAR, это неинтересно.

Конечно, вы захотите, чтобы ваше веб-приложение перезапустилось после обновления. Tomcat в режиме разработки будет отслеживать несколько файлов на предмет изменений; по умолчанию WEB-INF / web.xml является одним из них, поэтому обновите его вместе со всем, что вы обновляете, и вы должны вскоре перезагрузить приложение. В крайнем случае, вы можете использовать веб-приложение Manager, чтобы вывести приложение из спящего режима.

Для большего контроля и удобства вы в конечном итоге преуспели бы в том, чтобы использовать задачи Ant Tomcat (находящиеся рядом с дистрибутивом Tomcat, не входящие в ant!) Для перезапуска сервера и, возможно, для развертывания ваших изменений. Это займет немного времени, но это того стоит, так как вы захотите использовать его для каждого вашего проекта.

Answer 3

найти папку веб-приложения

загрузить файлы прямо в папку

например

/ путь к коту / webapp / myapp /

сохранить папку / path-to-tomcat / webapp / myapp / WEB-INF / lib и загрузить изменения в папку ur / path-to-tomcat / webapp / myapp / classes

затем используйте диспетчер tomcat для перезапуска приложения

Answer 4

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

Я согласен с duffymo ... 19MB на самом деле не так уж и велик ... есть ли причины для этого? Я бы не рекомендовал это.

Answer 5

Зачем вам менять свойство $ {shared.loader} по умолчанию для tomcat?

Answer 6

Странно, что Tomcat не может найти файлы jar. В любом случае, поместите все банки в общую папку ($ {catalina.home} / lib). (Это даже хуже, чем использование shared.folder, но оно должно работать для вас).

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

Еще одно примечание: вы должны делать это только в том случае, если у вас есть полный контроль над сервером, и вы единственный, кто устанавливает приложения.

Answer 7

Слушай Даффимо и Честехно.

Добавление банок к коту - верный путь к катастрофе.

Храните банки в каталоге веб-приложений.

Answer 8

1. WEB-INF / lib пуст?
2. Где находится log4j.jar?
3. Где находится spring.jar?

Это похоже на проблему видимости загрузчика классов.