NullPointerException when adding @NoCache annotation to a JAX-RS resource method

[FagnerMartinsBrack]

Hi @timowest,

I am sorry to bother but something very strange started happening in my build today related to the apt plugin, here is the offending build log: https://travis-ci.org/FagnerMartinsBrack/WebStories/builds/54536967

it throws an "execute error" when executing the "--- apt-maven-plugin:1.1.1:process (default)" goal:

java.lang.RuntimeException: java.lang.NullPointerException
    at com.sun.tools.javac.main.Main.compile(Main.java:469)
    at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132)
    at com.mysema.maven.apt.AbstractProcessorMojo.execute(AbstractProcessorMojo.java:314)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.NullPointerException
    at com.mysema.query.codegen.SimpleSerializerConfig.getConfig(SimpleSerializerConfig.java:29)
    at com.mysema.query.apt.DefaultConfiguration.<init>(DefaultConfiguration.java:133)
    at com.mysema.query.apt.jpa.JPAConfiguration.<init>(JPAConfiguration.java:72)
    at com.mysema.query.apt.jpa.JPAAnnotationProcessor.createConfiguration(JPAAnnotationProcessor.java:46)
    at com.mysema.query.apt.AbstractQuerydslProcessor.process(AbstractQuerydslProcessor.java:102)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1108)
    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
    at com.sun.tools.javac.main.Main.compile(Main.java:439)
    ... 23 more

This happened exactly after the following commit: https://github.com/FagnerMartinsBrack/WebStories/commit/11ebada01824777391d6f56097cab85bc548c884

Now, here is the problem: I have no idea where to start looking for it. This clearly seems to be happening due to some abstraction leak, but since I don't understand Maven and apt-maven-plugin internals, I have no idea where to start looking!

Do you have any idea of what could be happening in this case, maybe just to have something for me to look into? Could this be related to something that was already reported?

Local system data (if relevant):

• Windows 7 x64
• Maven 3.0.5 CLI
• jdk1.6.0_21
• querydsl version 3.2.4
• apt-maven-plugin version 1.1.1
• JBoss EAP 6.0
• Java EE 6 (JAX-RS 1.1)

pom.xml:

<plugin>
  <groupId>com.mysema.maven</groupId>
  <artifactId>apt-maven-plugin</artifactId>
  <version>1.1.1</version>
  <executions>
    <execution>
      <goals>
        <goal>process</goal>
      </goals>
      <configuration>
        <outputDirectory>target/generated-sources/java</outputDirectory>
        <processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
      </configuration>
    </execution>
  </executions>
</plugin>

NOTE: I didn't started yet to create a reduced test case in hope you could find the root cause by the symptoms.

Thanks.

[Shredder121]

Hi, this occasionally happens when there are compiler errors on a field. We get elements from javac as an annotation processor, and when there are compiler errors, javac for some reason also returns non related elements (that are erroneous, and have null properties as you can see by the NPE).

Could you maybe check to see if there are no uncommitted changes?

If there are errors like @NoCache is not an annotation type, that is a compiler error

[FagnerMartinsBrack]

Hi @Shredder121, thanks for the answer!

No, there is no uncommited changes and eclipse doesn't point any compile error. But maybe this is related to the fact org.jboss.resteasy.annotations.cache.NoCache represents a package inside an artifact that is not present physically in the project, Eclipse adds the JBoss libraries to the workspace in order to avoid compile errors, but those classes are available in the JBoss server at runtime.

I will take a look for any evidence that this is indeed what is causing this problem.

In the mean time, do you agree this is an abstraction leak from apt-maven-plugin? It is pretty hard to infer a classpath issue from the NPE error message, do you think it is possible to provide a better message for this problem?

Note: I vaguely remember of something like this happening a long time ago, but the root cause was something else.

[FagnerMartinsBrack]

Yeah, the problem was really related to my classpath. Maven didn't know about my dependencies that were added by JBoss Tools. To fix this I removed the eclipse dependencies to see compile errors in eclipse before running the build.

Here is the build that fixes the issue: https://travis-ci.org/FagnerMartinsBrack/WebStories/builds/54607699

But I believe the issue still stands, is there a way to provide a clearer error message to avoid this abstraction leak? Or there's a limitation that prevents you to do so?

I see you mentioned:

when there are compiler errors, javac for some reason also returns non related elements

Is there a workaround that could provide a better error message? Maybe detect the NPE and do something about that?

Thanks again!

[Shredder121]

Yes, I believe there is a workaround for exactly that. If you ask for all elements annotated with @ImpossibleAnnotation you could filter out the bogus elements. You can then precisely say which elements are at fault.

I still have to see if that is practical, but it looks like a very reproducible way of going about this.

As for the clearer error message, I agree that it should be done, and a way back (with PR #34) I wanted to add support for 'generic' messages from javac/apt. I have some code that does this, just not the effective code that prints the actual error, since I still had to see if it was practical or not.

[FagnerMartinsBrack]

Well then, it seems at least this was useful to document a valid use case :D