Sun.reflect.annotation.TypeNotPresentExceptionProxy ошибка при развертывании web-ear

Когда я пытаюсь развернуть ejd-ear, веб-ухо на сервер GlassFish. Я добавил зависимость клиента ejb в веб-проекте. Ejb-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)

Любые идеи?

Ответы

Ответ 1

Я думаю, что лучший способ - поставить точку разрыва в конструкторе java.lang.TypeNotPresentException и проверить второй аргумент типа Throwable, чтобы узнать причину ошибки

Ответ 2

С тем же исключением недавно с JUnit. Ситуация была такой:

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

Проблема в том, что JVM не смог обработать MyTestClass, потому что он отсутствовал зависимостями в пути к классам (отсутствовал другой JAR файл). Но исключение не предоставило информации о том, какой класс отсутствует.

Решение было временно добавить статический блок инициализации в MySuite, который создает экземпляр MyTestClass:

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

это заставляет JVM сначала запускать статический блок, пытаться создать экземпляр MyTestClass, узнать отсутствующий класс и сообщить о правильном исключении. Затем вы можете добавить отсутствующую зависимость и удалить временный статический блок.

Ответ 3

На самом деле мы просто столкнулись с тем же Исключением. У нас есть проект, который мы переводим с Java на Kotlin. В проекте все тестовые классы были написаны в Котлине, поэтому мы назвали папку src/test/kotlin. Мы также настроили наш pom в соответствии с разделом "Компиляция источников Kotlin и Java" в документации Kotlin.

То, что мы забыли, это определение тестового каталога, описанное в разделе "Компиляция только исходного кода Kotlin":

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

Также было немного запутанно, что автоматическая компиляция IntelliJ скомпилировала все тестовые классы по мере необходимости, а затем также была выполнена сборка maven. Только после a mvn clean test произошел TypeNotPresentExceptionProxy.

Ответ 4

Решение:

  • Подключиться с отладки к серверу Glassfish
  • Вставить точку разрыва в строку
    • java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
  • Разверните приложение.

Во время развертывания вы остановитесь несколько раз в этой точке разрыва. См. эту ссылку и помните о последнем, прежде чем возникнет ошибка развертывания. Затем проверьте аннотации в последнем классе this. Вы также можете поставить точку останова в метод AnnotationParser.parseClassArray, но скомпилированный код и точка прерывания метода очень медленно. (В моем случае с точкой разрыва метода я не мог наконец использовать приложение depoy).

Ответ 5

Это также может произойти в следующей ситуации:

Проект A - это некоторая библиотека, проект maven в вашем затмении. Он имеет класс с именем org.exmaple.Foo, который находится в каталоге src/test/java/.

в вашем проекте B, где возникает ошибка, вы пытаетесь получить доступ к этому классу. Но это невозможно.

Eclipse не будет жаловаться, потому что он "знает" оба класса. Если вы выполняете mvn clean install в проекте, который не работает, maven даст вам правильное сообщение об ошибке.

Я думаю, что этот эрро может произойти с Кеплера, но я не уверен. По крайней мере, он все еще присутствует в Луне:)

Ответ 6

Проблема конфликтует с файлом Jar. Проверьте список файлов jar внутри папки war file lib. Удалите ненужные и конфликтующие файлы jar. Затем развертывание будет успешным.

Ответ 7

Ошибка TypeNotPresentExceptionProxy не является определенной для конкретной зависимости и зависит от каждого пути к классам проекта. Итак, проверьте ваше дерево зависимостей maven. Например, однажды я попал в эту ошибку, когда у меня было две зависимости JUnit, поэтому в пути к классам было две версии аннотаций JUnit.

Вы можете установить точку останова в некоторых методах класса "java.lang.Class":

Например:

java.lang.Class.getAnnotation 
java.lang.Class.getAnnotations

После этого вы сможете обнаружить, какой класс вызывает проблему... найдите в классе аннотации и проверьте путь к классам на предмет неясностей.