Проблема загрузчика классов в Weblogic 10.3

Question

Резюме

Приложение, которое не изменилось структурно или изменило код, теперь испытывает проблемы пути к классам. Единственное, что изменилось, так это среда, в которой он был построен (новая коробка Solaris).

Сервер приложений: weblogic 10.3

Maven-War-плагин: 2,3

Ошибка

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

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

Насколько нам известно, все, что изменилось, - это новая сборочная коробка, из которой отдел сборки строит файл войны.

Тестирование завершено

Если я создаю войну в своей локальной среде (windows) и развертываю ее на сервере weblogic environment (unix box), проблем не возникает.

Однако, когда он построен на сборочном ящике (Solaris), а затем я разверну его в той же среде, я получаю проблему.

Я сравнил два военных файла и не нашел различий.

Чтобы подтвердить то, что я заподозрил (сначала выбрав неправильный класс на пути к классам), я собрал пакет, исключив неправильную версию, и неожиданный сюрприз сработал. Weblogic classloader явно загружает этот неправильный класс раньше другого.

Проблема все еще существует, мне нужно определить причину, чтобы это произошло внезапно.

Вопрос

Каковы правила для загрузчика классов weblogic, с точки зрения решения, какая зависимость в lib загружается первой?

И как возможно, что это поведение могло измениться между двумя разными войнами, которые в точности совпадают, за исключением номера версии в МАНИФЕСТЕ?

Большое спасибо,

Редактирование пользователя

По запросу дерева зависимостей Maven:

[INFO] com.xxx.web:adminapp:war:100462.7
[INFO] +- junit:junit:jar:4.11:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- struts:struts:jar:1.2.4:compile
[INFO] |  +- commons-beanutils:commons-beanutils:jar:1.6.1:compile
[INFO] |  +- commons-collections:commons-collections:jar:2.1:compile
[INFO] |  +- commons-digester:commons-digester:jar:1.5:compile
[INFO] |  |  \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] |  +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] |  +- commons-validator:commons-validator:jar:1.1.3:compile
[INFO] |  +- oro:oro:jar:2.0.7:compile
[INFO] |  +- antlr:antlr:jar:2.7.2:compile
[INFO] |  \- commons-lang:commons-lang:jar:2.6:compile (version managed from 2.0)
[INFO] +- displaytag:displaytag:jar:1.2:compile
[INFO] |  +- com.lowagie:itext:jar:1.3:compile
[INFO] |  +- org.slf4j:jcl104-over-slf4j:jar:1.4.2:compile
[INFO] |  \- org.slf4j:slf4j-log4j12:jar:1.4.2:compile
[INFO] |     +- org.slf4j:slf4j-api:jar:1.4.2:compile
[INFO] |     \- log4j:log4j:jar:1.2.13:compile
[INFO] +- taglibs:request:jar:1.0.1:compile
[INFO] +- org.apache.poi:poi:jar:3.8:compile
[INFO] |  \- commons-codec:commons-codec:jar:1.4:compile (version managed from 1.5)
[INFO] +- javax.servlet:servlet-api:jar:2.5:provided
[INFO] +- javax.servlet:jsp-api:jar:2.0:provided
[INFO] +- com.xxx.busservices:cdm:jar:623377.7:compile
[INFO] +- com.xxx.busservices:homeratingservice-java-client:jar:1011147.2:compile
[INFO] +- com.xxx.busservices:motorratingservice-java-client:jar:1011147.2:compile
[INFO] +- com.xxx.techservices:entrefdata-java-client:jar:1011147.2:compile
[INFO] +- com.xxx.techservices:auditservice-java-client:jar:626434.4:compile
[INFO] +- com.xxx.framework:framework:jar:626434.4:compile
[INFO] +- com.xxx.ibis:xxx-logging:jar:956942.1:compile
[INFO] +- weblogic:wlfullclient:jar:10.3:provided
[INFO] +- commons-fileupload:commons-fileupload:jar:1.2.2:compile
[INFO] \- commons-io:commons-io:jar:2.1:compile

cdm.jar содержит класс FactorValueLite, который является правильной версией и в пределах motorratingservice-java-client.jar также существует этот класс, который является неправильной версией, этот jar, кажется, загружается в путь к классам первым.

Answer 1

Я подозреваю, что у вас есть устаревшие артефакты в ваших локальных репозиториях (на машине, которую вы создаете), где они выходят из строя.

Попробуйте либо удалить его, либо указать другой путь (только для тестирования). Например:

mvn clean package -Dmaven.repo.local=/tmp/repository

Если это пройдет, то исправить это просто: удалите репозиторий.

Answer 2

Вы можете получить URL Class.getProtectionDomain().getCodeSource().getLocation() ("file: jar:...") на использованный jar. Я думаю, это разные jar-файлы в каталоге lib сервера приложений.