Re: Problems creating custom appender using JPMS service in 3.0.0-beta3

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