web-dev-qa-db-fra.com

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

Lorsque j'essaie de déployer ejd-ear, web-ear sur un serveur glassfish ..__, j'ai ajouté une dépendance client ejb dans un projet Web . Mais lorsque j'essaie de déployer Web-ear, cela jette une exception.

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?

deploymentmavenglassfishejb-3.0
32
Oops

Je pense que le meilleur moyen est de mettre un point d'arrêt dans le constructeur de Java.lang.TypeNotPresentException et de vérifier le deuxième argument de type Throwable pour connaître la cause première. 

45
lab bhattacharjee

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 JVM n'a pas pu traiter MyTestClass car il lui manquait des dépendances dans le chemin d'accès aux classes (un autre fichier JAR manquait). Mais l'exception n'a fourni aucune information sur la classe manquante.

La solution était de temporairement ajouter un bloc d’initialisation statique à MySuite, qui instancie MyTestClass:

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

jVM doit d’abord exécuter le bloc statique, essayer d’instancier MyTestClass, rechercher la classe manquante et signaler une exception appropriée. Ensuite, vous pouvez ajouter la dépendance manquante et supprimer le bloc statique temporaire.

23
tfager

En fait, nous avons juste rencontré la même exception. Nous avons actuellement un projet que nous transférons de Java à Kotlin. Dans le 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 la documentation Kotlin .

Ce que nous avions oublié, c’était la définition du répertoire de test décrite dans la section «Compiler le code source de Kotlin uniquement»:

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

Il a également été un peu déroutant que la compilation automatique IntelliJ compile toutes les classes de test selon les besoins et que, par la suite, la construction de maven soit un succès. Seulement après un mvn clean test, la TypeNotPresentExceptionProxy est apparue.

2
Stefan Tomm

Solution:

  1. Connectez-vous avec le débogage au serveur Glassfish
  2. Placez le point de rupture en ligne
    • Java.lang.Class.initAnnotationsIfNecessary (Class.Java:3070)
  3. Déployez votre application.

Lors du déploiement, vous vous arrêterez plusieurs fois à ce point d'arrêt. Voir this référence et souvenez-vous de la dernière avant que l’erreur de déploiement ne survienne. Vérifiez ensuite les annotations de la dernière " this " class . Vous pouvez également 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 ne pouvais pas enfin déposer l'application).

1
Cherry

Cela peut aussi arriver dans la situation suivante:

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

dans votre projet B où l'erreur se produit, 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 utilisez mvn clean install sur le projet qui ne fonctionne pas, Maven vous donnera un message d'erreur approprié.

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

1
Zarathustra

Le problème est en conflit avec le fichier Jar. Vérifiez la liste des fichiers jar dans le dossier lib du fichier war. Supprimez les fichiers JAR inutiles et conflictuels. Ensuite, le déploiement sera réussi.

0
surender reddy

L'erreur TypeNotPresentExceptionProxy n'est pas spécifique à une dépendance particulière et dépend du chemin d'accès aux classes de chaque projet. Vérifiez donc votre arborescence de dépendances maven. Par exemple, je suis tombé dans cette erreur une fois lorsque j'avais deux dépendances de JUnit, de sorte qu'il y avait deux versions des annotations JUnit dans le classpath.

Vous pouvez placer un point d'arrêt dans certaines des méthodes de la classe "Java.lang.Class":

Par exemple:

Java.lang.Class.getAnnotation 
Java.lang.Class.getAnnotations

Après cela, vous serez en mesure de déterminer la classe à l'origine du problème ... recherchez des annotations dans la classe et vérifiez si votre classpath présente des ambiguïtés.

0
Ariel Carrera