Странное поведение Spring на Jetty, когда spring.jar находится в WEB-INF / lib / вместо classpath - PullRequest
Новая
       27

Странное поведение Spring на Jetty, когда spring.jar находится в WEB-INF / lib / вместо classpath

1 голос
/ 21 октября 2009

Я использую Eclipse с плагином run-jetty-run для запуска моих веб-приложений J2EE. Мой проект использует Spring, а конфигурация Spring использует такие вещи, как HttpInvokerProxy и свойства placeholder.

  1. Когда пружинные банки находятся на пути к классам (я имею в виду настроенный на вкладке «путь к классам» в «конфигурации запуска») и внешнем (не в WEB-INF / lib), все работает нормально.
  2. Но когда я помещаю spring.jar (или все весенние jar-файлы) в каталог WEB-INF / lib / (+ указанный в пути к классам), проблема начинается. Я пробовал с обоими значениями Jetty parentLoaderPriority :
    1. когда parentLoaderPriority равен true, я получаю жалобу от Xerces, утверждающую, что он не может проверить XSD в spring.xml (поэтому я предполагаю, что встроенная в Jetty другая версия xerces конфликтует с моей)
    2. когда parentLoaderPriority равен false, заполнитель свойства больше не работает и (я попытался заменить его на прямые значения) Spring также не может преобразовать HttpInvokerProxy в правильный интерфейс, как некоторые классы отсутствуют
  3. Наконец, когда я оставляю все свои jar-файлы в WEB-INF / lib и удаляю соответствующие записи пути к классам, он не может найти классы: я получаю исключение ClassDefNotFoundException com / google / common / collect / Lists, хотя google-collection. jar находится в WEB-INF / lib и содержит файл класса ... Это с обоими значениями parentLoaderPriority .

Метод # 3 отлично работает в Tomcat. Итак, я думаю, что у этого реактивного запуска есть какая-то конфигурация загрузки классов, которую я делаю неправильно?

1 Ответ

1 голос
/ 09 января 2010

Похоже, ваше приложение использует что-то на «внешнем» пути к классам (я назову это X) и передаю ему ссылку; это прекрасно работает, потому что "external" находится в родительском загрузчике классов для вашего приложения.

«X» затем использует ссылку, чтобы сделать что-то с пружиной. Однако spring находится на пути к классам вашего приложения, а X - на внешнем пути к классам. Поэтому пружина не видна Х, отсюда и ошибка.

Как вы обнаружили, добавление пружины во внешний путь к классам является правильным решением. Это также должно работать, если пружина находится как во внешних, так и в веб-приложениях.

Что такое «Х»? Наиболее вероятным кандидатом была бы регистрация общих ресурсов, у которой долгая история шумихи с загрузчиками классов. Возможно, вы захотите использовать вместо этого реализацию slf4j (например, Logback) и предоставить интерфейс ведения общего журнала через jcl-over-slf4j

Ресурсы:

...