Импорт вызывает ошибку verifyError? Ява

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

Я собираюсь описать настройку проекта точно так же, как в Netbeans.

Раньше у меня был проект веб-приложения Java, состоящий из множества пакетов исходного кода и множества библиотек.

Теперь мы распределили пакеты исходного кода по трем проектам Java-приложений. Нам нужен четвертый проект веб-приложения Java, куда мы импортируем эти три проекта в виде библиотек, и мы можем протестировать веб-службы RESTful, реализованные в коде.

Проблема в том, что для того, чтобы все операции импорта работали после рефакторинга, мы в итоге включили все библиотеки из исходного проекта во все четыре новых проекта. Мы почти уверены, что это вызывает java.lang.VerifyError, которую мы не могли решить в течение нескольких дней.

После рефакторинга основного проекта на 3 части они включают друг друга следующим образом (они также включают каждую библиотеку, использовавшуюся в исходном проекте):

A (A imports B and C)
|
B (B imports C)
|
C

Проект веб-приложения импортирует все: три проекта исходного кода плюс все библиотеки, используемые в основном проекте. Если мы их не включим, при попытке протестировать веб-службы RESTful мы не увидим ресурсы слева.

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

ERROR MESSAGE: 
Exception in thread "main" java.lang.VerifyError: (class: com/couchbase/client/CouchbaseClient, method: asyncQueryAndReduce signature: (Lcom/couchbase/client/protocol/views/View;Lcom/couchbase/client/protocol/views/Query;)Lcom/couchbase/client/internal/HttpFuture;) Incompatible argument to function

Я получил это сообщение об ошибке при тестировании простого класса, который создал клиент Couchbase. Когда мы тестируем настоящие веб-сервисы, мы получаем ту же ошибку с более крупной и сложной трассировкой стека, но в основном с той же ошибкой.

FULL ERROR WHEN WE RUN THE WEB SERVICE:
java.lang.VerifyError: (class: com/couchbase/client/CouchbaseClient, method: asyncGetView signature: (Ljava/lang/String;Ljava/lang/String;)Lcom/couchbase/client/internal/HttpFuture;) Incompatible argument to function
at models.cache.utils.PoolableCouchbaseClientObjectFactory.makeObject(PoolableCouchbaseClientObjectFactory.java:53)
at models.cache.utils.PoolableCouchbaseClientObjectFactory.makeObject(PoolableCouchbaseClientObjectFactory.java:24)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188)
at models.cache.utils.CouchbaseConnector.connectCache(CouchbaseConnector.java:48)
at models.cache.controllers.SessionCacheHandler.setUserSession(SessionCacheHandler.java:65)
at services.handlers.LoginPOSTHandler.run(LoginPOSTHandler.java:296)
at services.LoginResource.post(LoginResource.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:168)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:259)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

java import verifyerror
person Alex    schedule 26.12.2012    source источник
comment
Можете ли вы добавить точное сообщение об ошибке VerifyError?   -  person micha    schedule 26.12.2012
comment
Опубликуйте точное сообщение об ошибке и трассировку стека, а также код, вызывающий ее. Я думаю, вы просто делаете неверные предположения. VerifyError не имеет ничего общего с импортом.   -  person JB Nizet    schedule 26.12.2012
comment
Я разместил это. Любые идеи? Я предположил, что это было из-за импорта, потому что сбой - это метод кушетки, который не сработал до рефакторинга.   -  person Alex    schedule 26.12.2012
comment
Кажется, вы используете другую версию CouchDB, отличную от той, с которой вы скомпилировали   -  person Raffaele    schedule 26.12.2012
comment
Возможно, проблема связана со строкой 53 в PoolableCouchbaseClientObjectFactory. Вставьте и эту строку. Обратите внимание, что, если я правильно помню, в Netbeans есть опасная функция, которая может упаковывать некомпилируемый код.   -  person Raffaele    schedule 26.12.2012
comment
Клиент CouchbaseClient = новый CouchbaseClient (this.serverList, this.bucketName, this.bucketPassword);   -  person Alex    schedule 26.12.2012

Ответы (1)


arrow_upward
0
arrow_downward

Java — компилируемый язык, поэтому есть два момента:

  1. Этап компиляции, когда компилятору предлагается использовать ваши операторы импорта для создания полных имен для разрешения ваших символов. После того, как байт-код был сгенерирован, он не содержит никакого оператора импорта, потому что импорт — это исходный код, он никогда не существует во время выполнения. В байт-коде каждый символ полностью определяется именем пакета.
  2. Проверка во время выполнения, когда проверяющие JVM заботятся о сопоставлении вызова метода с определением этого метода. Это когда выбрасывается VerifyError

Это означает, что в загрузке определений заинтересованы два разных агента: компилятор и JVM. Оба могут загружать определения классов из CLASSPATH, но, например, во время выполнения загрузчик классов вашего веб-приложения также может загружать классы из каталога WEB-INF/lib.

При разработке библиотек вы можете добавить архивы в свой путь сборки (или вы можете использовать инструмент управления зависимостями, такой как Apache Ivy или Maven), но вам не следует упаковывать зависимости в выходные данные процесса сборки. Пользователь должен предоставить необходимые библиотеки.

Итак, например, вы разрабатываете A и добавляете проект B и C в путь сборки, чтобы компилятор мог разрешать символы и успешно компилировать все, но окончательный JAR должен содержать только классы для проекта A. То же самое для B, и, очевидно, для С.

Когда вы разрабатываете свое веб-приложение, у вас будут A, B, C в вашем пути сборки, но вы также должны позаботиться о настройке процесса сборки, который копирует все в WEB-INF/lib перед развертыванием, иначе вы столкнетесь отсутствующие библиотеки во время выполнения.

Как я уже говорил ранее, вы можете организовать свой проект с помощью Maven, или вы можете управлять зависимостями с помощью Ivy, или вы можете просто использовать проприетарный проект Netbeans, если Netbeans является стандартом в вашей команде и вы не хотите внедрять другие технологии. Если вы выберете способ Netbeans, вы должны добавить проекты Netbeans в качестве зависимостей (NB, Netbeans projects , а не только файлы JAR), чтобы при обновлении библиотеки ваш сценарий развертывания веб-приложения автоматически получал изменения и у вас нет конфликтующих библиотек, установленных в разных местах.

person Raffaele    schedule 26.12.2012
comment
Моим трем новым проектам нужны более или менее одинаковые библиотеки. Есть ли способ включить их только в проект C, а затем B и A получить их, когда они импортируют C? - person Alex; 26.12.2012
comment
Пожалуйста, не используйте термин import, он вводит в заблуждение, поскольку это допустимая инструкция Java, заставляющая компилятор разрешать символы. Если вы имеете в виду упаковать необходимые JAR-файлы в C, чтобы они автоматически были доступны для всех проектов, требующих C, то да, есть, но это плохая практика и может сломаться. Вам лучше использовать структуру зависимостей, которая имеет понятие транзитивных зависимостей и управляет всем за вас. Maven и Ivy могут это сделать наверняка, я не знаю, управляет ли Netbeans транзитивными отложениями, но вам действительно следует искать Maven, потому что это де-факто стандарт Java. - person Raffaele; 26.12.2012