Ошибка sun.reflect.annotation.TypeNotPresentExceptionProxy при развертывании веб-уха - PullRequest
37 голосов
/ 02 июля 2011

Когда я пытаюсь развернуть ejd-ear, web-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)

Есть идеи?

Ответы [ 7 ]

50 голосов
/ 05 декабря 2013

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

23 голосов
/ 23 апреля 2012

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

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

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

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

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

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

2 голосов
/ 20 октября 2017

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

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

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

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

1 голос
/ 11 июля 2014

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

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

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

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

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

1 голос
/ 12 августа 2013

Решение:

  1. Соединение с отладкой на сервере Glassfish
  2. Поместите точку останова в линию
    • java.lang.Class.initAnnotationsIfNecessary (Class.java:3070)
  3. Разверните ваше приложение.

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

0 голосов
/ 30 апреля 2019

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

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

Например:

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

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

0 голосов
/ 20 июля 2017

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

...