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

I should add that there were two main drivers for the way Plugin support =
was changed in 3.0.
1. Stop using a custom Log4jPlugins.dat file. Using a data file created =
all the problems with shading. Placing all the entries into a Java class =
solved this easily.
2. Use ServiceLoader to locate plugins instead of traversing =
ClassLoaders. We still end up traversing ClassLoaders but in a way that =
is very well supported by the JDK.

So in reality Log4jPlugins.dat was what was converted to be a Java =
service, not the plugins themselves.

Ralph

> On Dec 4, 2024, at 10:08=E2=80=AFPM, Ralph Goers =
<[email protected]> wrote:
>=20
> Some huge points are being overlooked in this discussion.
>=20
> 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.
>=20
> Ralph
>=20
>> 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=94f=
or 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=99=
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?
>>>=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
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>=20