Some huge points are being overlooked in this discussion.
1. A Plugin is NOT a Java service. You cannot manually create the
META-INF/services entry for your plugin as the plugin system won’t recognize it.
2. A Plugin service is a collection of plugins. This is intentional as loading
all the plugins one by one via ServiceLoader would be very slow. I recall that
some testing was done around that when this was first implemented. If you look
at the Log4jPlugins.java class generated by the annotation processor you will
see that all the plugins for the module are there. It is much easier to do this
with a tool than construct it manually.
3. While we could have used a JSON or properties file we would have ended up
right where we are with 2.x with creating shaded jars being a problem and
needing a custom transformer. Using a Java class file with ServiceLoader avoids
this.
4. Again, module-info.java does NOT reference individual plugins. Instead, it
references the generated Log4jPlugins.java class.
5. Log4jPlugins.java contains almost no code - it has a single method that
simply returns the list of plugin entries that are provided in the module.
Ralph
> On Dec 4, 2024, at 6:15 AM, Volkan Yazıcı <vol...@yazi.ci> wrote:
>
> I agree with Pavel that users should only be required to
>
> 1. Provide the interface implementation
> 2. Create the associated `META-INF/services` file entry
> 3. [For Java 9 and above] Update their `module-info.java` accordingly
>
> Anything more than this is non-idiomatic. Telling users "but processors are
> helpful", "you can manually create the Java file registering your plugin",
> etc. is beating around the bush.
>
> On Fri, Nov 29, 2024 at 10:26 AM PavelTurk <pavelturk2...@gmail.com> wrote:
>
>> Hi Piotr,
>>
>> On 11/29/24 10:07, Piotr P. Karwasz wrote:
>>> Hi Pavel,
>>>
>>> On 28.11.2024 19:26, PavelTurk wrote:
>>>> Thank you very much for your detailed and quick help.
>>>>
>>>> However, to tell the truth, I’m a bit confused. I’ve been waiting for a
>> long time for Log4j to finally work according to the JPMS rules. But in
>> your message, you talk about compile-time and, as I understood, the use of
>> some plugin-processor (from your project pom):
>>>>
>>>> <annotationProcessorPaths>
>>>> <path>
>>>> <groupId>org.apache.logging.log4j</groupId>
>>>> <artifactId>log4j-plugin-processor</artifactId>
>>>> <version>3.0.0-beta3</version>
>>>> </path>
>>>> </annotationProcessorPaths>
>>>>
>>>> Doesn’t all this completely contradict JPMS?
>>>> (...)
>>>> By the way, I noticed something seemed off when I saw code duplication
>> in your project:
>>>>
>>>> @Configurable(elementType = Appender.ELEMENT_TYPE, printObject = true)
>>>> @Plugin(ConsoleAppender.PLUGIN_NAME)
>>>> public final class ConsoleAppender...
>>>>
>>>> and
>>>>
>>>> PluginEntry.builder()
>>>> .setKey("console")
>>>> .setClassName("org.apache.logging.log4j.core.appender.ConsoleAppender")
>>>> .setName("Console")
>>>> .setNamespace("Core")
>>>> .setElementType("appender")
>>>> .setPrintable(true)
>>>> .get(),
>>>>
>>>> Or am I mistaken (which is always possible) and misunderstood
>> everything?
>>>
>>> We have an annotation processor that automatically generates the
>> required `PluginService` implementation, I don't see how that contradicts
>> the principles behind JPMS.
>> ...
>>
>> Let me explain my point of view. But first of all, I want to emphasize
>> that I’m not claiming to be right—I could very well be wrong. I’m simply
>> saying that using a processor seems incorrect to me.
>>
>> In the world of JPMS, there’s a service, we implement it, and we add it. I
>> haven’t heard of a service + PROCESSOR that needs to be used. Can you point
>> out any other projects that involve a service + processor? The reasoning is
>> that we should only need to know the INTERFACE, and we’ll handle the
>> IMPLEMENTATION ourselves. After all, it’s possible to do without it—for
>> example, by writing a PluginService manually, which would scan the module
>> itself and return the necessary classes or just data(entries) about them.
>> That’s why I said that using a processor here seems odd to me. In general,
>> I think code generation should only be used as a last resort—for example,
>> for JPA metamodels—but that’s just my opinion.
>>
>> I assume module-info was also generated automatically. The problem is that
>> it’s not present in log4j-core-3.0.0-beta3-sources.jar see [1], but it does
>> exist in log4j-core-3.0.0-beta3.jar see [2]. Additionally, it’s not in the
>> repository see [3]. So, it is not possible to see what is in this file. Or
>> was I looking in the wrong place?
>>
>> [1]
>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-beta3/log4j-core-3.0.0-beta3-sources.jar
>> [2]
>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-beta3/log4j-core-3.0.0-beta3.jar
>> [3]
>> https://github.com/apache/logging-log4j2/tree/rel/3.0.0-beta3/log4j-core/src/main/java
>>
>> Best regards, Pavel
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>>
