sun.reflect.annotation.TypeNotPresentExceptionProxy błąd podczas wdrażania web-ear

Question

Kiedy próbuję wdrożyć ejd-ear, web-ear na serwerze glassfish. Dodałem zależność klienta ejb w projekcie WWW. The ejb-ear wdraża się pomyślnie. Ale kiedy próbuję wdrożyć web-ear, rzuca wyjątek.

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) 

Wszelkie pomysły?

Answer 1

Ostatnio ten sam wyjątek z JUnit. Sytuacja była tak:

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

Problem jest to, że JVM nie był w stanie przetworzyć MyTestClass ponieważ brakowało zależności w ścieżce klasy (inny plik JAR brakowało). Ale wyjątek nie dostarczył informacji o tym, której klasy brakowało.

Rozwiązanie było tymczasowo dodać statycznego bloku inicjalizacji MySuite, który tworzy wystąpienie MyTestClass:

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

ten powoduje JVM uruchomić statyczny blok najpierw spróbować instancji MyTestClass, dowiedzieć się brakującą klasę i zgłoś odpowiedni wyjątek. Następnie możesz dodać brakującą zależność i usunąć tymczasowy blok statyczny.

Answer 2

Rozwiązanie:

1. Połącz z debugowania do serwera GlassFish
2. Put punkt przerwa w linii
   • java.lang.Class.initAnnotationsIfNecessary (Class.java:3070)
3. Wdróż swoją aplikację.

Podczas wdrażania będziesz zatrzymywać się kilka razy w tym punkcie przerwania. Zobacz ten odnośnik i pamiętaj, że wystąpił ostatni błąd związany z wdrożeniem. Następnie sprawdź adnotacje w ostatniej "tej klasie". Można także umieścić punkt przerwania w metodzie AnnotationParser.parseClassArray, ale jest to skompilowany kod, a punktem przerwania metody jest bardzo powolny. (W moim przypadku z punktem przerwania metody nie mogłem w końcu użyć aplikacji).

Answer 3

Myślę, że najlepszym sposobem jest umieszczenie punktu przerwania w konstruktorze java.lang.TypeNotPresentException i sprawdzić drugi argument typu Throwable poznać przyczynę

Answer 4

Może również zdarzyć się w następującej sytuacji:

Projekt A to jakaś biblioteka, projekt maven w twoim zaćmieniu. Ma klasę o nazwie org.exmaple.Foo, która znajduje się w katalogu src/test/java/.

w projekcie B, w którym wystąpił błąd, próbujesz uzyskać dostęp do tej klasy. Ale to nie jest możliwe.

Eclipse nie będzie narzekał, ponieważ "wie" obie klasy. Jeśli używasz mvn clean install w projekcie, który nie działa, maven wyświetli odpowiedni komunikat o błędzie.

Myślę, że to erro może wystąpić od czasu Keplera, ale nie jestem pewien. Przynajmniej wciąż jest obecny w Lunie :)

Answer 5

Problem jest sprzeczny z plikiem Jar. Zweryfikuj listę plików jar w folderze plików wojennych. Usuń niepotrzebne i konfliktowe pliki JAR. Następnie wdrożenie zakończy się pomyślnie.

Answer 6

Po prostu wpadliśmy na ten sam wyjątek. Mamy projekt, który obecnie przenosimy z Java do Kotlina. W projekcie wszystkie klasy testów zostały napisane w Kotlin i dlatego nazwaliśmy folder src/test/kotlin. Skonfigurowaliśmy również pom zgodnie z sekcją "Kompilowanie źródeł Kotlin i Java" w Kotlin documentation.

Co zapomnieliśmy było określenie katalogu badanie opisane w „jedynego Kompilacja Kotlin kodu źródłowego” odcinku:

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

Stwierdzono również nieco mylące, że auto kompilacja IntelliJ skompilowany wszystkich klas testowych zgodnie z wymaganiami, a następnie również pomyślne wykonanie maven build. Dopiero po mvn clean test wystąpił TypeNotPresentExceptionProxy.