Classloader Filtering - PullRequest
Новая
       52

Classloader Filtering

2 голосов
/ 28 декабря 2011

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

У меня есть веб-приложение (файл войны).Jar, относящийся к apache-commons-lang, добавлен в библиотеку WEB-INF вместе с другим файлом jar.Однако более старая версия jar, относящаяся к apache-commons-lang, также присутствует в системной библиотеке, и при развертывании файла jar в системном classpath имеет преимущество, и я получаю ошибку «classnotfound».Предпочтительные web-inf-классы должны быть указаны для классов, указанных в WEB-INF, чтобы иметь приоритет над классами, присутствующими в System Classloader. Однако я бы хотел, чтобы только этот конкретный jar имел приоритет над системным загрузчиком классов.Мне посоветовали использовать «Filtering Classloaders» в weblogic, когда я опубликовал похожую проблему.Это решение прекрасно работает, когда у меня есть ухо.Однако я не смогу добавить weblogic-application.xml в файл war, и я не могу использовать эту концепцию фильтрации загрузчиков классов.Есть ли выход?Спасибо.

Ответы [ 4 ]

1 голос
/ 29 декабря 2011

Я не очень хорошо знаком с WebLogic, но если вы знаете, как используется более новый jar-файл и ввод в этот код так же прост, как создание экземпляра класса и выполнение одного метода запуска, вы можете избежать использования индивидуального загрузчика классов?См. Пример на http://tshrestha.blogspot.com/2011/12/using-custom-classloader.html

Но я признаю, что некоторые гуру WebLogic знают, как этого добиться с некоторой конфигурацией самого WebLogic.

0 голосов
/ 23 мая 2012

Вики, у меня была такая же проблема, как и у тебя. Решение, которое сработало для меня, - это создание папки / lib в домене (часть этого есть в документации по веб-журналу), добавление любых сторонних JAR-файлов, которые необходимо переопределить, и указание этой библиотеки в PRE_CLASSPATH переменная в файле startWeblogic.cmd .

В моем случае, weblogic имел более старую версию commons-lang, и это вызывало конфликт. Поскольку у меня не было развертывания EAR, решение weblogic-application.xml было бесполезным. После того, как я добавил следующее в мой pre_classpath -
set PRE_CLASSPATH =% PRE_CLASSPATH%;% DOMAIN_HOME% / lib / commons-lang-2.5.jar;

моя проблема была решена.

0 голосов
/ 21 марта 2012

Я не гуру веблогики, но я вижу два пути (не пробовал, а только догадывался)

1) оставил только нужные файлы jar 'предпочтения веб-инф-классов' в WEB-INF и переехалостальные в другое место и укажите их в MANIFEST.MF of war

2) связать эту войну пустым ухом и указать все банки в MANIFEST.MF уха и указать класс предпочтений в weblogic-applicationXMLИдея состоит в том, чтобы сделать войну и слух частью одного и того же приложения, чтобы веб-приложение могло использовать один и тот же загрузчик классов (вместо использования предпочитаемого-веб-класса)

РЕДАКТИРОВАТЬ: для первого пункта япроверили, что weblogic игнорирует файл файла манифеста войны.Так что первый сол не работает.Также о втором золе, если в ухе нет ejbs, weblogic слепо игнорирует Manifest of ear.Таким образом, вы должны переместить библиотеки WAR в APP-INF \ lib или просто в lib dir of ear и указать пакет предпочтений apache-commons-lang в weblogic-application.xml. В любом случае, не думайте, что это эффективное решение (особенно еслине хочу создавать ухо только ради этого)

0 голосов
/ 21 февраля 2012

Один из моих коллег отметил, что наличие соответствующих пакетов, указанных в weblogic.xml, решит проблему. Тем не менее, чтобы попробовать это все же. 

    <wls:prefer-application-packages>
        <wls:package-name>javax.faces.*</wls:package-name>
        <wls:package-name>com.sun.faces.*</wls:package-name>
        <wls:package-name>javax.xml.*</wls:package-name>
        <wls:package-name>org.apache.xerces.*</wls:package-name>
        <wls:package-name>antlr.*</wls:package-name>
        <wls:package-name>org.apache.log4j.*</wls:package-name>
        <wls:package-name>org.apache.commons.*</wls:package-name>
    </wls:prefer-application-packages>
...