ctubbsii commented on issue #3771: URL: https://github.com/apache/logging-log4j2/issues/3771#issuecomment-3309148059
> Hi [@ctubbsii](https://github.com/ctubbsii), > > > I don't think the warning is friendly enough. I want to completely ignore the GraalVmProcessor... I don't need it (it's not common). I just want the PluginProcessor to generate the Log4j2Plugins.dat for my custom AbstractAppender implementation. > > Thanks for raising this. Could you elaborate a bit on what you find unfriendly in the current message? For reference, this is what’s being printed today: > > ``` > The `GraalVmProcessor` annotation processor is missing the recommended `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options. > To follow the GraalVM recommendations, please add the following options to your build tool: > -Alog4j.graalvm.groupId=<groupId> > -Alog4j.graalvm.artifactId=<artifactId> > ``` The unfriendly part is that I could find no way to cause the processor to completely skip its work. I don't need it to run, but am forced to use the autodiscovery process, which picks this one up. I couldn't configure it to be skipped. I had to set some value. The problem with this is that it caused an error in my multi-module project configuration. I'm not entirely sure why, but I could not get a configuration to work. Although it is just a "warning", we run maven-compiler-plugin with 0 warnings (we see warnings as untriaged potential bugs, and require they all be triaged and either fixed or suppressed). So, we use `-Xlint:all`. But this one cannot be configured to be suppressed. > > The goal of the `GraalVmProcessor` is fairly minimal: it adds a small JSON descriptor to your JAR that can help downstream users build native images if they ever use your plugin. From that perspective, I’m not sure there’s a strong reason to exclude it entirely. Our "plugin" is just a small custom Log4j AbstractAppender implementation that is used internal to the project for (optionally) receiving forwarded logs to a custom monitoring/alerting web service. There would never be a reason to use this for our case. We are not writing general purpose plugins for reuse. Also, we only need it for a single module in a multi-module build. Our compiler-maven-plugin is at the root of the project, and is (at least, was) relatively quite simple. Updating to 2.25 increases the complexity of our build in order to work around this issue (see the changes to the profiles in `pom.xml` in apache/accumulo#5890). > > > Unfortunately, this new GraalVmProcessor has these noisy warnings, and that kills my build, because I run with 0 warnings. It's not clear how to disable this processor, unless I explicitly enumerate all the processors I want to use, just to implicitly exclude this one that I don't want. Ideally, if the prerequisite options don't exist, the processor doesn't run. It shouldn't just spit out warnings for everybody who doesn't want this processor. > > I understand the frustration. A couple of clarifications that might help: > > * Since Log4j Core **2.25.1**, the `<groupId>` and `<artifactId>` are no longer prerequisites. If the processor runs and finds metadata to write, it will generate the JSON resource automatically. The only trade-off is that you don’t get to control its location unless you pass the options explicitly. > * Regarding “disabling” processors: unfortunately, that’s not something Log4j can handle on its own. The Java compiler doesn’t provide a general way to ignore a specific annotation processor. In fact, the JDK has moved in the opposite direction: starting with [JDK 23](https://inside.java/2024/06/18/quality-heads-up/), you either need to list the processors explicitly or use `-proc:full`. I understand Java doesn't have a way to exclude a processor from its autodiscovery process, but setting a system property that the processor understands as "I should exit successfully without doing any work" would be quite convenient to be able to tell the processor itself that it should be skipped (similar to how Maven plugins can be skipped in a Maven lifecycle build where the plugin is configured). > > > (Also, a bit of a complaint about the Log4j2Plugins.dat... I really wish log4j had gone with the Java ServiceLoader, and standard META-INF/services/ files like slf4j did, then I wouldn't have to rely on the log4j annotation processor to create the file.) > > In hindsight, we agree that introducing a custom `Log4j2Plugins.dat` format was not ideal (especially given the inexplicable popularity of the questionable shading practice). However: > > * In **Log4j Core 3**, this has been addressed: you can now implement your own `PluginService` without relying on the `PluginProcessor`. > * It doesn't seem fair to compare Log4j Core 2.0 with SLF4J 2.0.0, since they were released 8 years apart. For historical context: My intention wasn't to compare log4j choices with slf4j. My intention was to point out the utility of the ServiceLoader - slf4j was just a quick example. Any other project that uses ServiceLoader would have sufficed as an equivalent example. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
