导致verifyError的导入？ java的

时间：2012-12-26 14:08:13

标签： java import verifyerror

我正在开发一个项目，我们想要重新使用类似的近期项目的代码。但是，这一次，我们希望将代码拆分为三个库，以便在将来我们将重新使用此代码的项目中更容易使用。

我将描述项目设置，就像我在Netbeans中一样。

之前，我有一个Java Web应用程序项目，包含许多源代码包和一堆库。

现在，我们已将源代码包分发到三个Java Application项目中。我们需要一个新的Java Web应用程序项目，我们将这三个项目作为库导入，我们可以测试代码中实现的RESTful Web服务。

问题在于，为了使所有导入在重构后都能正常工作，我们最终在所有四个新项目中包含了原始项目中的所有库。我们非常肯定这会导致java.lang.VerifyError我们几天都无法解决。

在将主项目重构为3个部分后，它们相互包含如下（它们还包括原始项目中使用的每个库）：

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

Web应用程序项目导入所有内容：三个源代码项目以及主项目中使用的所有库。如果我们不包含它们，当我们尝试测试RESTful Web服务时，我们无法看到左侧的资源。

问题是，是否有关于如何组织我们的库的建议，以便我们停止获取此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客户端的简单类时，我收到了错误消息。当我们测试真实的Web服务时，我们会得到相同的错误，堆栈跟踪更大，更复杂，但基本上都是相同的错误。

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)

1 个答案:

答案 0 :(得分：0)

Java是一种编译语言，因此有两个时刻：

  1. 编译步骤，当告诉编译器使用您的import语句时，构建限定名称以解析符号。生成字节码后，它不包含任何import语句，因为import是源代码，它们在运行时从不存在。在字节码中，每个符号都使用包名完全限定。
  2. 运行时验证，当JVM验证程序负责将方法调用与该方法的定义进行匹配时。这是VerifyError被抛出的时间

    3. 这意味着有两种不同的代理对加载定义感兴趣：编译器和JVM。两者都可以从CLASSPATH加载类定义，但是在运行时，例如，您的webapp类加载器也可以从WEB-INF / lib目录加载类。

    在开发库时，您可以将归档添加到构建路径（或者您可以使用Apache Ivy或Maven之类的依赖项管理工具），但不应在构建过程的输出中打包依赖项。由用户提供所需的库。

    因此，例如，您开发A并将B和C项目添加到构建路径，因此编译器可以解析符号并愉快地编译所有内容，但最终的JAR必须只包含项目A的类.B的相同，显然对于C。

    当您开发Web应用程序时，您的构建路径中将包含A，B，C，但您还应该在部署之前设置一个复制WEB-INF / lib中所有内容的构建过程，否则您将在运行时遇到缺少的库。

    正如我之前所说，您可以使用Maven组织项目，或者您可以使用Ivy管理依赖项，或者您可以简单地使用专有的Netbeans项目，如果Netbeans是您团队中的标准并且您不想采用其他技术。如果选择Netbeans方式，则应将Netbeans项目添加为依赖项（NB，Netbeans 项目，而不仅仅是JAR文件），以便在更新库时，您的Web应用程序部署脚本会自动获取修改和你没有在不同的地方安装冲突库。

相关问题
最新问题