sun.reflect.annotation.TypeNotPresentExceptionProxy erreur lors du déploiement de web-ear

Question

Lorsque j'essaie de déployer ejd-ear, web-ear sur le serveur glassfish. J'ai ajouté une dépendance client ejb dans le projet web. L'ejb-ear se déploie avec succès. Mais lorsque j'essaie de déployer web-ear, une exception est levée.

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)

Des idées ?

Answer 1

Je pense que la meilleure solution est de placer un point d'arrêt dans le constructeur de java.lang.TypeNotPresentException et de vérifier le second argument de type Throwable pour connaître la cause première.

Answer 2

J'ai eu la même exception récemment avec JUnit. La situation était la suivante :

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

Le problème est que la JVM n'a pas pu traiter MyTestClass car il lui manquait des dépendances dans le classpath (un autre fichier JAR était manquant). Mais l'exception ne fournit aucune information sur la classe manquante.

La solution consistait à temporairement ajouter un bloc d'initialisation statique à MySuite, qui instancie MyTestClass :

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

Cela amène la JVM à exécuter le bloc statique en premier, à essayer d'instancier MyTestClass, à trouver la classe manquante et à signaler une exception appropriée. Ensuite, vous pouvez ajouter la dépendance manquante et supprimer le bloc statique temporaire.

Answer 3

Nous venons de rencontrer la même exception. Nous avons un projet que nous transférons actuellement de Java à Kotlin. Dans ce projet, toutes les classes de test ont été écrites en Kotlin et nous avons donc nommé le dossier src/test/kotlin . Nous avons également configuré notre pom conformément à la section 'Compilation des sources Kotlin et Java' dans le manuel de l'utilisateur. Documentation Kotlin .

Ce que nous avions oublié, c'est la définition du répertoire de test décrite dans la section ' Compilation du code source Kotlin uniquement' :

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

Il est également un peu déroutant que l'auto-compilation d'IntelliJ ait compilé toutes les classes de test comme requis et qu'ensuite la construction de maven soit réussie. Ce n'est qu'après une mvn clean test el TypeNotPresentExceptionProxy survenu.

Answer 4

Solution :

1. Se connecter avec debug au serveur Glassfish
2. Mettre le point d'arrêt dans la ligne
   • java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
3. Déployez votre application.

Pendant le déploiement, vous vous arrêterez plusieurs fois à ce point de rupture. Voir este référence et se souvenir de la dernière avant que l'erreur de déploiement ne survienne. Vérifiez ensuite les annotations dans la dernière " este classe ". Vous pouvez aussi mettre un point d'arrêt dans la méthode AnnotationParser.parseClassArray, mais il s'agit d'un code compilé et le point d'arrêt de la méthode est très lent . (Dans mon cas, avec le point d'arrêt de la méthode, je n'ai finalement pas pu déployer l'application).

Answer 5

Cela peut également se produire dans la situation suivante :

le projet A est une bibliothèque, un projet maven dans votre eclipse. Il possède une classe nommée org.exmaple.Foo qui se trouve dans le src/test/java/ répertoire.

dans votre projet B où l'erreur se produit vous essayez d'accéder à cette classe. Mais ce n'est pas possible.

Eclipse ne se plaindra pas car il "connaît" les deux classes. Si vous exécutez mvn clean install sur le projet qui ne fonctionne pas, maven vous donnera un message d'erreur approprié.

Je pense que cette erreur peut se produire depuis Kepler, mais je n'en suis pas sûr. Au moins, il est toujours présent dans Luna :)