2

同様の最近のプロジェクトのコードを再利用したいプロジェクトに取り組んでいます。ただし、今回は、コードを 3 つのライブラリに分割して、このコードを再利用する将来のプロジェクトでも簡単に作業できるようにします。

Netbeans の場合と同じように、プロジェクトのセットアップについて説明します。

以前は、多くのソース コード パッケージと多数のライブラリで構成される Java Web アプリケーション プロジェクトがありました。

これで、ソース コード パッケージを 3 つの Java アプリケーション プロジェクトに配布しました。これら 3 つのプロジェクトをライブラリとしてインポートし、コードに実装された RESTful Web サービスをテストできる 4 つ目の Java Web アプリケーション プロジェクトが必要です。

問題は、リファクタリング後にすべてのインポートを機能させるために、元のプロジェクトのすべてのライブラリを 4 つの新しいプロジェクトすべてに含めることになったことです。java.lang.VerifyErrorこれが、数日間解決できなかった原因であると確信しています。

メイン プロジェクトを 3 つの部分にリファクタリングした後、次のように相互に含めます (元のプロジェクトで使用されたすべてのライブラリも含まれます)。

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

Web アプリケーション プロジェクトは、3 つのソース コード プロジェクトと、メイン プロジェクトで使用されるすべてのライブラリをすべてインポートします。それらを含めないと、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

ソファベース クライアントを作成する単純なクラスをテストしているときに、そのエラー メッセージが表示されました。実際の 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 はコンパイル済み言語であるため、次の 2 つの瞬間があります。

  1. コンパイラーが import ステートメントを使用するように指示されたときのコンパイル手順で、シンボルを解決するための修飾名を作成します。バイトコードが生成されると、 import ステートメントは含まれません。インポートはソースコードのものであり、実行時に存在することはないためです。バイトコードでは、すべてのシンボルがパッケージ名で完全修飾されています。
  2. JVM verfiers がメソッド呼び出しとそのメソッドの定義との照合を処理するときの実行時検証。これは、VerifyErrorがスローされるときです。

これは、コンパイラと JVM という 2 つの異なるエージェントが定義のロードに関与していることを意味します。どちらも CLASSPATH からクラス定義をロードできますが、たとえば、実行時に webapp クラスローダーが WEB-INF/lib ディレクトリからクラスをロードすることもあります。

ライブラリを開発する場合、ビルド パスにアーカイブを追加できます (または、Apache Ivy や Maven などの依存関係管理ツールを使用できます) が、ビルド プロセスの出力に依存関係をパックしないでください。必要なライブラリを提供するのはユーザー次第です。

したがって、たとえば、A を開発し、B および C プロジェクトをビルド パスに追加すると、コンパイラはシンボルを解決してすべてを問題なくコンパイルできますが、最終的な JAR にはプロジェクト A のクラスのみを含める必要があります。B についても同様であり、明らかにCの場合。

Web アプリケーションを開発するとき、ビルド パスに A、B、C がありますが、展開する前に WEB-INF/lib 内のすべてをコピーするビルド プロセスの設定にも注意する必要があります。実行時に不足しているライブラリ。

前に述べたように、Netbeans がチームの標準であり、他のテクノロジを採用したくない場合は、プロジェクトを Maven で整理するか、Ivy で依存関係を管理するか、独自の Netbeans プロジェクトを使用することができます。Netbeans の方法を選択した場合は、Netbeans プロジェクトを依存関係 (JAR ファイルだけでなく、NB、Netbeansプロジェクト) として追加する必要があります。これにより、ライブラリが更新されたときに、webapp 展開スクリプトが自動的に変更を取得し、競合するライブラリがなくなります。さまざまな場所に設置されています。

于 2012-12-26T14:26:20.840 に答える