WAS 6.1 java.lang.VerifyError: нарушено ограничение загрузки класса - PullRequest
Новая
       39

WAS 6.1 java.lang.VerifyError: нарушено ограничение загрузки класса

10 голосов
/ 19 мая 2010

В Linux используется среда WAS 6.1, в которой развертывается веб-приложение, использующее классы из xercesImpl.jar.

Из-за ограничений политики компании приложение должно быть развернуто с Настройки: 

Class Loader Order
    Classes loaded with parent class loader first
->  Classes loaded with application class loader first

WAR class loader policy
    Class loader for each WAR file in application
->  Single class loader for application

Файл WAR содержит копию файла xercesImpl.jar, того самого файла, который был в пути к классам, когда приложение было скомпилировано.

При запуске веб-приложения, когда Spring пытается разобрать его конфиги, оно броски: 

java.lang.VerifyError: class loading constraint violated 
    (class: org/apache/xerces/jaxp/DocumentBuilderImpl 
    method: parse(Lorg/xml/sax/InputSource;)Lorg/w3c/dom/Document;)

АНАЛИЗ ТАК ДАЛЕЕ

Похоже, что WAS обеспечивает реализацию org.apache.xerces.jaxp.DocumentBuilderImpl, потому что мы можем удалить xercesImpl.jar из файла WAR и по-прежнему выдает ту же ошибку (не ClassNotFoundException). Таким образом, WAS, кажется, разрешает ссылки используя свою собственную копию, которая несовместима с ссылками в нашем скомпилированные файлы классов. Тем не менее, единственный другой экземпляр «xercesImpl.jar» Я могу найти (кроме копии, развернутой с нашим приложением) в каталоге deploytool, который, кажется, находится за пределами сервера приложений.

Я отсканировал все банки в WAS (все 1300 из них) с 

for i in `find . -name \*.jar`; do jar tvf $i|grep -qi xerces && echo $i ; done

и обнаружил, что ./java/jre/lib/xml.jar содержит все классы в org.apache.xerces.*, так что это вероятно, когда загрузчик классов разрешает ссылку.

ЗДЕСЬ ЧАСТНАЯ ЧАСТЬ:

Если мы изменим на «родительский загрузчик классов первым», мы не увидим исключения. Это идет вразрез с ожидаемым поведением. Мы ожидаем, что с «Сначала загрузчик классов приложения» будет использовать файл xercesImpl.jar, который мы и использовать версию WAS, только если мы установили «родительский загрузчик классов» первый ". Это, кажется, назад от того, что мы на самом деле видим.

ВОПРОС:

Как параметр делегирования загрузчика классов взаимодействует с вышеуказанной информацией, чтобы привести к наблюдаемому поведению?

Ответы [ 5 ]

14 голосов
/ 19 мая 2010

Ваша WAR также включает классы org.xml.sax или org.w3c.dom, а затем вы ссылаетесь на класс, который находится за пределами вашего приложения, который также ссылается на эти классы. Это создает сценарий, в котором ваш загрузчик классов приложений может видеть два экземпляра одного класса, что является ошибкой связывания.

Например, если ваше приложение использует javax.xml.bind.Unmarshaller.unmarshal (InputSource), тогда Unmarshaller будет загружен из JDK, а класс Unmarshaller будет иметь видимость только для JDK InputSource. Когда ваше приложение создает свой InputSource, оно будет загружать класс из WAR (потому что «приложение сначала»), а затем ваше приложение будет пытаться передать экземпляр WAR InputSource в JDK Unmarshaller, который может принимать только экземпляр входной источник JDK.

Есть два решения:

  1. Удалите все jar-файлы API из своего приложения и используйте их из JDK. Например, удалите банку, содержащую org.xml.sax или org.w3c.dom.
  2. Включите в свою WAR все библиотеки, которые ссылаются на классы, на которые вы хотите ссылаться. Например, включите копию библиотеки JAXB в вашу WAR.

По моему опыту, ошибки компоновки довольно сложно отследить, потому что JVM дают паршивую информацию о том, что вызывает добавление компоновок. Я обычно включаю трассировку загрузчика классов, воспроизводю проблему и затем иду назад, пока не найду класс, загруженный извне приложения, который «звучит как», он может ссылаться на класс, который, как известно, существует внутри приложения.

0 голосов
/ 28 марта 2018

Может быть, уже слишком поздно, но мы решили эту проблему, удалив эту строку в server.xml:

JAXB-2,1

0 голосов
/ 11 апреля 2015

Отключить проверку байт-кода

java.lang.VerifyError - Исключительная ситуация во время выполнения как только файл класса загружен в Websphere JVM, то следующим процессом будет изменение байтового кода. Во время проверки байтового кода, если наш класс нарушает ограничения JVM, появляется эта ошибка.

отключить проверку байт-кода. Перейти к

консоль администратора -> сервер1 -> управление Java и процессами ->process definition-> Аргументы JVM`

И в аргументах JVM передайте следующую строку 

 -Xverify:none

и в рабочей области откройте XML-файл ApplicationDeploymentDescriptor, перейдите на вкладку развертывания, выберите PARENT_LAST для войны, а также для первого варианта. это останавливает ошибки проверки XML.

0 голосов
/ 24 сентября 2014

Нашей проблемой было развертывание на WAS 8.5.

В нашем веб-приложении есть клиент веб-сервиса, сгенерированный cxf. Нет проблем.

Когда мы добавили тика-парсер для обнаружения mime-типов, мы получили эту проблему.

Мы исключили три зависимости: 

<dependency>
            <groupId>org.apache.tika</groupId>
            <artifactId>tika-parsers</artifactId>
            <version>${apache.tika.version}</version>
            <exclusions>
                <exclusion>
                    <artifactId>geronimo-stax-api_1.0_spec</artifactId>
                    <groupId>org.apache.geronimo.specs</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>xercesImpl</artifactId>
                    <groupId>xerces</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>xmlbeans</artifactId>
                    <groupId>org.apache.xmlbeans</groupId>
                </exclusion>
            </exclusions>
        </dependency>

Как только они были исключены, наше приложение успешно запустилось.

0 голосов
/ 19 мая 2010

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

Да, это правильно, это единственный способ увидеть такое поведение. Я могу предложить вам взглянуть на «У вас действительно есть классные загрузчики?» говорите, так как нет единого или краткого ответа на ваш вопрос.

http://www.slideshare.net/guestd56374/do-you-really-get-class-loaders http://www.parleys.com/#sl=2&st=5&id=1585

...