ppkarwasz commented on issue #3771:
URL:
https://github.com/apache/logging-log4j2/issues/3771#issuecomment-3306858654
Hi @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 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.
> 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`.
> (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:
* Back in 2014 (Log4j 2.0), the `Log4j2Plugins.dat` and
`log4j-provider.properties` mechanisms were designed, while SLF4J 1.7.x still
required providers to define a specific class name. This approach at least
allowed multiple plugin JARs to coexist.
* Log4j Core moved to `ServiceLoader` for providers in **2.9.0** (2017),
around the same time SLF4J 1.8.x began introducing similar changes (though that
version never saw a final release).
* SLF4J didn’t officially adopt `ServiceLoader` until **2.0.0 in 2022**.
--
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]
