Skip to content
This repository has been archived by the owner on Jul 30, 2021. It is now read-only.

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

Open
FagnerMartinsBrack opened this issue Mar 16, 2015 · 5 comments

Comments

@FagnerMartinsBrack
Copy link

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: web-stories/WebStories@11ebada

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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

@FagnerMartinsBrack FagnerMartinsBrack changed the title NullPointerExcetption when adding @NoCache annotation to a JAX-RS resource method NullPointerException when adding @NoCache annotation to a JAX-RS resource method Mar 16, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants