sun.reflect.annotation.TypeNotPresentExceptionProxy error when deploy web-ear_问答_开发者

When I try to deploy ejd-ear, web-ear on to glassfish server. I added an ejb client dependency in web project. The ejb-ear deploys successfully. But when I try to deploy web-ear, it throws an exception .

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(HttpProtocolChai开发者_如何学Gon.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)

Any ideas?

I think the best way is to put a break point in the constructor of java.lang.TypeNotPresentException and check the second argument of type Throwable to know the root cause

Had the same exception recently with JUnit. The situation was like this:

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

Problem is that JVM was unable to process MyTestClass because it was missing dependencies in the classpath (another JAR file was missing). But the exception provided no information on which class was missing.

Solution was to temporarily add a static initialization block to MySuite, that instantiates MyTestClass:

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

this causes JVM to run the static block first, try to instantiate MyTestClass, find out the missing class and report a proper exception. Then you can add the missing dependency and remove the temporary static block.

We actually just ran into the same Exception. We have a project that we currently transfer from Java to Kotlin. In the project, all test classes were written in Kotlin and therefore we named the folder src/test/kotlin. We also configured our pom according to the 'Compiling Kotlin and Java sources' section in the Kotlin documentation.

What we had forgotten was the test directory definition described in the ' Compiling Kotlin only source code' section:

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

It has also been a bit confusing that the IntelliJ auto compilation compiled all test classes as required and afterwards also the maven build was successful. Only after a mvn clean test the TypeNotPresentExceptionProxy occurred.

Solution:

Connect with debug to Glassfish server
Put break point into line
- java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
Deploy your application.

While deploying you will stop several times at this break point. See this reference and remember the last before deployment error arise. Than check Annotations in last "this" class. You can also put break point into AnnotationParser.parseClassArray method, but it is compiled code and break point on the method is very slow. (In my case with method break point I could not depoy application at last).

This can also happen in the following situation:

project A is some library, a maven project in your eclipse. It has a class named org.exmaple.Foo which is in the src/test/java/ directory.

in your project B where the error occurs you are try to access this class. But this isn't possible.

Eclipse won't complain because it "knows" both classes. If you are running mvn clean install on the project that does not work maven will give you a proper error message.

I think this erro can occur since Kepler but I am not sure. At least it is still present in Luna :)

The issue is conflicting with Jar file. Verify the list of jar files inside war file lib folder. Remove unnecessary and conflicting jar files. Then the deployment will be successful.

TypeNotPresentExceptionProxy error is not specific to a particular dependency and depends on each project's classpath. So verify your maven dependencies tree. For example, I fell into this error one time when I had two dependencies of JUnit so there were two versions of JUnit annotations in the classpath.

You can put a breakpoint in some of the methods of class "java.lang.Class":

For example:

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

After that, you will be able to discover which class cause the problem... search inside the class for annotations and check your classpath for ambiguities.