sun.reflect.annotation.TypeNotPresentExceptionProxy error al implementar web-ear

Question

Cuando intento implementar ejd-ear, web-ear en el servidor glassfish. Agregué una dependencia de cliente ejb en un proyecto web. El ejb-ear se implementa con éxito. Pero cuando intento desplegar web-ear, arroja una excepción.

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) 

¿Alguna idea?

Answer 1

Tuvo la misma excepción recientemente con JUnit. La situación era la siguiente:

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

El problema es que la JVM no pudo procesar MyTestClass porque faltaba dependencias en la ruta de clase (otro archivo JAR faltaba). Pero la excepción no proporcionó información sobre qué clase faltaba.

solución fue temporalmente añadir un bloque de inicialización estática a MySuite, que instancia MyTestClass:

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

esto causa JVM para ejecutar el bloque estático en primer lugar, tratar de crear una instancia MyTestClass, averiguar la clase que falta y informa una excepción adecuada. Luego puede agregar la dependencia faltante y eliminar el bloque estático temporal.

Answer 2

Solución:

1. Conectar con depuración de servidor Glassfish
2. Poner punto de ruptura en la línea
   • java.lang.Class.initAnnotationsIfNecessary (Class.java:3070)
3. Implementa tu aplicación.

Durante la implementación, se detendrá varias veces en este punto de interrupción. Consulte esta referencia y recuerde el último antes de que surja el error de implementación. Luego marque Anotaciones en la última clase "this". También puede colocar el punto de interrupción en el método AnnotationParser.parseClassArray, pero es código compilado y punto de corte en el método es muy lento. (En mi caso, con el punto de ruptura del método, no pude descargar la aplicación por fin).

Answer 3

Creo que la mejor manera es poner un punto de quiebre en el constructor de java.lang.TypeNotPresentException y comprobar el segundo argumento de tipo Throwable saber la causa

Answer 4

Esto también puede ocurrir en la siguiente situación:

proyecto A es una biblioteca, un proyecto de maven en tu eclipse. Tiene una clase llamada org.exmaple.Foo que se encuentra en el directorio src/test/java/.

en su proyecto B donde se produce el error, intenta acceder a esta clase. Pero esto no es posible

Eclipse no se quejará porque "conoce" ambas clases. Si está ejecutando mvn clean install en el proyecto que no funciona, maven le dará un mensaje de error apropiado.

Creo que este error puede ocurrir desde Kepler, pero no estoy seguro. Al menos todavía está presente en Luna :)

Answer 5

El problema está en conflicto con el archivo Jar. Verifique la lista de archivos jar dentro de la carpeta war file lib. Elimine los archivos jar innecesarios y conflictivos. Entonces la implementación será exitosa.

Answer 6

En realidad, nos encontramos con la misma excepción. Tenemos un proyecto que actualmente transferimos de Java a Kotlin. En el proyecto, todas las clases de prueba se escribieron en Kotlin y, por lo tanto, hemos denominado la carpeta src/test/kotlin. También configuramos nuestro pom de acuerdo con la sección 'Compilación de fuentes de Kotlin y Java' en el Kotlin documentation.

Lo que habíamos olvidado fue la definición del directorio de ensayo descrito en la sección 'sólo Compilación Kotlin código fuente':

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

También ha sido un poco confuso que la compilación automática IntelliJ compilado todas las clases de prueba según sea necesario y luego también la construcción maven fue exitosa. Solo después de un mvn clean test ocurrió el TypeNotPresentExceptionProxy.