deployment - Error de sun.reflect.annotation.TypeNotPresentExceptionProxy al implementar web-ear

maven glassfish

Question

Cuando trato de desplegar ejd-ear, web-ear en el servidor glassfish. Agregué una dependencia de cliente ejb en proyecto web. El ejb-ear se despliega con éxito. Pero cuando intento desplegar web-ear, lanza 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)

¿Algunas ideas?

Answer 1

Creo que la mejor manera es poner un punto de ruptura en el constructor de java.lang.TypeNotPresentException y verificar el segundo argumento de tipo Throwable para conocer la causa raíz

Answer 2

De hecho, 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, src/test/kotlin 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 la documentación de Kotlin .

Lo que habíamos olvidado era la definición del directorio de prueba descrita en la sección ''Compilación del código fuente único de Kotlin'':

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

También ha sido un poco confuso que la compilación automática de IntelliJ compiló todas las clases de prueba según sea necesario y, posteriormente, también la compilación de Maven fue exitosa. Solo después de una mvn clean test TypeNotPresentExceptionProxy produjo el TypeNotPresentExceptionProxy .

Answer 3

El problema está en conflicto con el archivo Jar. Verifique la lista de archivos jar dentro de la carpeta lib war file. Eliminar archivos jar innecesarios y en conflicto. Entonces el despliegue será exitoso.

Answer 4

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

El proyecto A es una biblioteca, un proyecto de Maven en tu eclipse. Tiene una clase llamada org.exmaple.Foo que está en el directorio src/test/java/ .

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

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

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

Answer 5

Solución:

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

Durante el despliegue, se detendrá varias veces en este punto de interrupción. Vea esta referencia y recuerde el último error de implementación antes de que surja. Que marque las anotaciones en la última clase " este ". También puede poner un punto de interrupción en el método AnnotationParser.parseClassArray, pero es un código compilado y el punto de interrupción en el método es muy lento . (En mi caso con el punto de interrupción del método no pude despoyar la aplicación por fin).

Answer 6

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

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

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

La solución fue agregar temporalmente un bloque de inicialización estático a MySuite, que crea una instancia de MyTestClass:

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

esto hace que JVM ejecute el bloque estático primero, intente crear una instancia de MyTestClass, busque la clase que falta e informe una excepción adecuada. Luego puede agregar la dependencia que falta y eliminar el bloque estático temporal.