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

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=E2=80=99t=
 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.=20
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=E2=80=AFAM, Volkan Yaz=C4=B1c=C4=B1 =
<[email protected]> wrote:
>=20
> I agree with Pavel that users should only be required to
>=20
>   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
>=20
> 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.
>=20
> On Fri, Nov 29, 2024 at 10:26=E2=80=AFAM PavelTurk =
<[email protected]> wrote:
>=20
>> Hi Piotr,
>>=20
>> On 11/29/24 10:07, Piotr P. Karwasz wrote:
>>> Hi Pavel,
>>>=20
>>> On 28.11.2024 19:26, PavelTurk wrote:
>>>> Thank you very much for your detailed and quick help.
>>>>=20
>>>> However, to tell the truth, I=E2=80=99m a bit confused. I=E2=80=99ve =
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):
>>>>=20
>>>>          <annotationProcessorPaths>
>>>>            <path>
>>>> <groupId>org.apache.logging.log4j</groupId>
>>>> <artifactId>log4j-plugin-processor</artifactId>
>>>>              <version>3.0.0-beta3</version>
>>>>            </path>
>>>>          </annotationProcessorPaths>
>>>>=20
>>>> Doesn=E2=80=99t all this completely contradict JPMS?
>>>> (...)
>>>> By the way, I noticed something seemed off when I saw code =
duplication
>> in your project:
>>>>=20
>>>> @Configurable(elementType =3D Appender.ELEMENT_TYPE, printObject =3D =
true)
>>>> @Plugin(ConsoleAppender.PLUGIN_NAME)
>>>> public final class ConsoleAppender...
>>>>=20
>>>> and
>>>>=20
>>>> PluginEntry.builder()
>>>>  .setKey("console")
>>>> =
.setClassName("org.apache.logging.log4j.core.appender.ConsoleAppender")
>>>>  .setName("Console")
>>>>  .setNamespace("Core")
>>>>  .setElementType("appender")
>>>>  .setPrintable(true)
>>>>  .get(),
>>>>=20
>>>> Or am I mistaken (which is always possible) and misunderstood
>> everything?
>>>=20
>>> We have an annotation processor that automatically generates the
>> required `PluginService` implementation, I don't see how that =
contradicts
>> the principles behind JPMS.
>> ...
>>=20
>> Let me explain my point of view. But first of all, I want to =
emphasize
>> that I=E2=80=99m not claiming to be right=E2=80=94I could very well =
be wrong. I=E2=80=99m simply
>> saying that using a processor seems incorrect to me.
>>=20
>> In the world of JPMS, there=E2=80=99s a service, we implement it, and =
we add it. I
>> haven=E2=80=99t 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=E2=80=99ll =
handle the
>> IMPLEMENTATION ourselves. After all, it=E2=80=99s possible to do =
without it=E2=80=94for
>> example, by writing a PluginService manually, which would scan the =
module
>> itself and return the necessary classes or just data(entries) about =
them.
>> That=E2=80=99s 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=E2=80=94fo=
r example,
>> for JPA metamodels=E2=80=94but that=E2=80=99s just my opinion.
>>=20
>> I assume module-info was also generated automatically. The problem is =
that
>> it=E2=80=99s 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=E2=80=99s=
 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?
>>=20
>> [1]
>> =
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-b=
eta3/log4j-core-3.0.0-beta3-sources.jar
>> [2]
>> =
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-b=
eta3/log4j-core-3.0.0-beta3.jar
>> [3]
>> =
https://github.com/apache/logging-log4j2/tree/rel/3.0.0-beta3/log4j-core/s=
rc/main/java
>>=20
>> Best regards, Pavel
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>=20
>>=20