Ошибка sun.reflect.annotation.TypeNotPresentExceptionProxy при развертывании веб-уха

Question

Ошибка sun.reflect.annotation.TypeNotPresentExceptionProxy при развертывании веб-уха

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

Есть идеи?

45

maven deployment glassfish ejb-3.0

Источник

user825471 01 июл '11 в 20:10

6 ответов

Другие вопросы по тегам maven deployment glassfish ejb-3.0

user1427694 05 дек '13 в 07:00 2013-12-05 07:00 · Answer 1 · 2013-12-05 07:00

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

66

Источник

user1427694 05 дек '13 в 07:00

user1351331 23 апр '12 в 12:46 2012-04-23 12:46 · Answer 2 · 2012-04-23 12:46

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

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

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

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

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

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

user6257938 20 окт '17 в 08:18 2017-10-20 08:18 · Answer 3 · 2017-10-20 08:18

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

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

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

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

user1251549 12 авг '13 в 07:46 2013-08-12 07:46 · Answer 4 · 2013-08-12 07:46

Решение:

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

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

user1248724 11 июл '14 в 17:53 2014-07-11 17:53 · Answer 5 · 2014-07-11 17:53

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

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

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

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

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

user2493852 29 апр '19 в 21:09 2019-04-29 21:09 · Answer 6 · 2019-04-29 21:09

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

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

Например:

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

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

user8337389 20 июл '17 в 10:01 2017-07-20 10:01 · Answer 7 · 2017-07-20 10:01

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

0

Источник

user8337389 20 июл '17 в 10:01