java.lang.VerifyError: Несовместимый аргумент для функции - PullRequest
0 голосов
/ 02 февраля 2011

У меня есть mavenized проект Spring 3, который прекрасно работает и работает на одной машине. точно такой же проект прекрасно работает на второй машине, но когда я пытаюсь перейти на страницу (ту, которая отлично работает на другой машине), я получаю следующую трассировку стека:

java.lang.VerifyError: (class: org/apache/jsp/tag/web/generate_002dvalidation_tag, method: _jspx_meth_c_005fset_005f13 signature: (Ljavax/servlet/jsp/tagext/JspTag;Ljavax/servlet/jsp/PageContext;[I)Z) Incompatible argument to function
    java.lang.Class.getDeclaredConstructors0(Native Method)
    java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
    java.lang.Class.getConstructor0(Class.java:2699)
    java.lang.Class.newInstance0(Class.java:326)
    java.lang.Class.newInstance(Class.java:308)
    org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:635)
    org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:52)
    org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:685)
    org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530)
    org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
    org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
    org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
    org.apache.jasper.compiler.Node$Root.accept(Node.java:495)
    org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
    org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:703)
    org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:210)
    org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
    org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
    org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
    org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:589)
    org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
    org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
    org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)
    org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
    org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)
    org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)
    org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
    org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
    org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Единственное различие, о котором я могу думать, - это версия Java.На машине, на которой работает проект, версия 6 обновляет 17, тогда как на второй машине (на которой проект не работает) версия 6 обновляется 22. Версия pom точно такая же.

ItПохоже, что проблема связана с пользовательским тегом, но я не могу понять, что это такое.Что может быть причиной этой проблемы?

ОБНОВЛЕНИЕ

Я взглянул на целевые каталоги на обеих машинах и заметил следующее:

  • На машине, где проект не работает, каталог lib имеет el-api-2.2.jar
  • На машине, где работает проект, есть папка tomcat в папке target, которая содержит следующее:
`-- tomcat
    |-- conf
    |   |-- tomcat-users.xml
    |   `-- web.xml
    |-- logs
    |-- webapps
    `-- work
        `-- localEngine
            `-- localhost
                `-- _
                    |-- org
                    |   `-- apache
                    |       `-- jsp
                    |           |-- tag
                    |           |   `-- web
                    |           |       |-- generate_002dvalidation_tag.class
                    |           |       `-- generate_002dvalidation_tag.java
                    |           `-- WEB_002dINF
                    |               `-- jsp
                    |                   `-- starship
                    `-- SESSIONS.ser

Этот каталог отсутствует на машине, на которой работает проект

  • На машине, на которой работает проект, имеется warкаталог под target, которого нет на машине, на которой проект не работает (однако обе машины создают файл war в каталоге target)

  • НаНа машине, на которой сборка не работает, файл war составляет 4 135 195 байт, тогда как на другой - 4 104 569 байт.Это различие связано с включением файла el-api-2.2.jar.

Я не уверен, что это значит.

Ответы [ 4 ]

1 голос
/ 02 февраля 2011

Согласно этот ответ ,

java.lang.VerifyError может быть результат, когда вы скомпилировали против другая библиотека, чем вы используете во время выполнения.

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

Вы случайно не скомпилировали его на Linux против Windowsy? Возможно, у вас может быть одна и та же библиотека с другой версией в classpath. В разных ОС порядок загрузки классов различен. На вашем компьютере сначала может быть загружен правильный файл JDK 6u17.

Обычно я открываю файл war в браузере 7zip и проверяю, есть ли одна и та же библиотека разных версий. Некоторые библиотеки используют другое имя артефакта, но фактически одно и то же, например яровое зерно и орг.

0 голосов
/ 24 декабря 2014

Хотя причина, упомянутая gigadot, верна, но я обязательно проверю ниже, прежде чем перейти к чему-то другому:

  1. Проверьте cglibs в моем пути к классам.
  2. Проверьте hibernate версии в моем classpath.

Скорее всего, наличие нескольких или конфликтующих версий любого из вышеперечисленных может вызвать неожиданные проблемы, такие как рассматриваемая.1011 *

0 голосов
/ 01 марта 2013

Согласно моему опыту, иногда проверки дают неправильные сведения о сложных дженериках.Кроме того, иногда контрольно-измерительные приборы могут создавать проблемы.Если вы знаете, что ошибка проверки не должна появляться, но она все равно появляется, проверку можно отключить с помощью параметра запуска -noverify.

Иногда ее также можно отключить по другим причинам, например производительности.

Подробнее об отключении проверки см. в этой теме .

0 голосов
/ 02 февраля 2011

Больше, чем в Java-версии, я думаю, что проблема связана с разницей в версиях Java EE библиотек.

Возможно ли, что две машины имеют разные серверы приложений или разные версии сервера приложений?Кроме того, библиотеки, предоставляемые контейнером (например, servlet-api.jar или jsp-api.jar), упаковываются на войне?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...