2

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

我将像在 Netbeans 中那样描述项目设置。

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

现在，我们已将源代码包分发到三个 Java 应用程序项目中。我们需要第四个 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)
4

1 回答 1

0

Java是一种编译语言，所以有两个时刻：

  1. 编译步骤，当编译器被告知使用您的导入语句时，构建限定名称以解析您的符号。一旦生成了字节码，它就不包含任何导入语句，因为导入是源代码的东西，它们在运行时永远不存在。在字节码中，每个符号都是完全限定的包名。
  2. 运行时验证，当 JVM 验证器负责将方法调用与该方法的定义匹配时。这VerifyError是抛出的时候

这意味着有两个不同的代理对加载定义感兴趣：编译器和 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 文件），这样当更新库时，您的 webapp 部署脚本会自动抓取修改并且您不会有冲突的库安装在不同的地方。

于 2012-12-26T14:26:20.840 回答