sun.reflect.annotation.TypeNotPresentExceptionProxyエラーWeb-earをデプロイするとき

Question

ejd-ear、web-earをglassfishサーバーにデプロイしようとしました。 Webプロジェクトにejbクライアント依存関係を追加しました。 ejb-earが正常にデプロイされます。しかし、Web-Earを展開しようとすると、例外がスローされます。

sun.reflect.annotation.TypeNotPresentExceptionProxy 
java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy 
    at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) 
    at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) 
    at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) 
    at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) 
    at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) 
    at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) 
    at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) 
    at java.lang.Class.getAnnotations(Class.java:3050) 
    at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:285) 
    at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195) 
    at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134) 
    at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606) 
    at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:459) 
    at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432) 
    at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408) 
    at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383) 
    at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246) 
    at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255) 
    at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:216) 
    at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165) 
    at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:180) 
    at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368) 
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) 
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) 
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) 
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) 
    at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) 
    at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) 
    at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) 
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) 
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) 
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) 
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) 
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) 
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) 
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) 
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) 
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) 
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) 
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) 
    at com.sun.grizzly.ContextTask.run(ContextTask.java:71) 
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) 
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) 
    at java.lang.Thread.run(Thread.java:662) 

Answer 1

JUnitで最近同じ例外がありました。 状況はこのようなものだった：

@SuiteClasses({MyTestClass.class}) 
public class MySuite { 
    ... 
} 

問題は、JVMが（別のJARファイルが欠落していた）、それはクラスパスに依存関係がありませんでしたので、MyTestClassを処理できませんでしたということです。しかし例外は、どのクラスが欠けていたかについての情報を提供しなかった。

ソリューションがMyTestClassをインスタンス化すること、MySuiteに静的な初期化ブロックを追加し、一時的ににした：

@SuiteClasses({MyTestClass.class}) 
public class MySuite { 
    static { 
     new MyTestClass(); 
    } 
} 

これが不足しているクラスを見つける、MyTestClassをインスタンス化しようとすると、最初の静的ブロックを実行するためにJVMを引き起こし、適切な例外を報告してください。次に、欠落している依存関係を追加し、一時的な静的ブロックを削除できます。

Answer 2

ソリューション：GlassFishサーバーへのデバッグと

1. 接続
ライン
• java.lang.Class.initAnnotationsIfNecessary（Class.java:3070）
2. に
3. 入れブレークポイントアプリケーションをデプロイします。

展開中、このブレークポイントで数回停止します。 の参考資料を参照し、展開エラーが発生する前の最後のことを覚えておいてください。最後に「this」クラスの注釈よりも AnnotationParser.parseClassArrayメソッドにブレークポイントを入れることもできますが、コンパイルされたコードで、メソッドのブレークポイントはと非常に遅いです。 （私の場合、メソッドのブレークポイントで私は最後にアプリケーションをdepoyできませんでした）。

Answer 3

私は最善の方法は、java.lang.TypeNotPresentExceptionのコンストラクタにブレークポイントを入れて、これがまた、以下の状況で発生することが根本的な原因

Answer 4

を知るためにThrowable型の第2引数をチェックすることだと思います。

プロジェクトAは、いくつかのライブラリ、あなたの日食のmavenプロジェクトです。 org.exmaple.Fooという名前のクラスがsrc/test/java/ディレクトリにあります。

エラーが発生したプロジェクトBでは、このクラスにアクセスしようとしています。しかし、これは不可能です。

Eclipseは、両方のクラスを「知っている」ため、不平を言うことはありません。 プロジェクトでmvn clean installを実行していて、mavenが動作しない場合は、適切なエラーメッセージが表示されます。

このエラーはケプラー以来発生する可能性がありますが、わかりません。少なくともLunaにはまだ存在しています:)

Answer 5

問題はJarファイルと競合しています。 warファイルlibフォルダ内のjarファイルのリストを確認します。不要で競合するjarファイルを削除します。その後、展開は成功します。

Answer 6

私たちは実際に同じExceptionを実行しました。私たちは、現在JavaからKotlinに転送しているプロジェクトを持っています。プロジェクトでは、すべてのテストクラスはKotlinで書かれていたので、フォルダ名はsrc/test/kotlinとしました。また、Kotlin documentationの「KotlinとJavaソースのコンパイル」セクションに従って、pomを構成しました。 IntelliJの自動コンパイルがすべてのテストクラスをコンパイルしたことをまた少し混乱してい

<build> <testSourceDirectory>${project.basedir}/src/test/kotlin</testSourceDirectory> </build>

：私たちは忘れていた何

「をコンパイルKotlinのみソースコード」のセクションに記載された試験ディレクトリ定義しました必要に応じて、その後もMavenビルドが成功しました。 mvn clean testの後でのみ、TypeNotPresentExceptionProxyが発生しました。