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
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 plug
I had to put some mysterious dot file in the root of my Maven module to get
my plugin to work. The only way I found this is by comparison with another
module but not all modules have this file.
Gary
On Wed, Dec 4, 2024, 8:16 AM Volkan Yazıcı wrote:
> I agree with Pavel that users should only be
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 proc
Not particularly about those annotations. The plugin service metadata is
sufficient for that.
> On Dec 2, 2024, at 14:29, Piotr P. Karwasz wrote:
>
> Hi Matt,
>
> On 2.12.2024 19:36, Matt Sicker wrote:
>> For one, you’ll need to annotate your constructor arguments with the
>> appropriate @Plu
Hi Matt,
On 2.12.2024 19:36, Matt Sicker wrote:
For one, you’ll need to annotate your constructor arguments with the
appropriate @Plugin annotations (@PluginElement and @PluginAttribute mainly) to
know how to bind config data to your plugin. That is required regardless of
whether you’re manua
For one, you’ll need to annotate your constructor arguments with the
appropriate @Plugin annotations (@PluginElement and @PluginAttribute mainly) to
know how to bind config data to your plugin. That is required regardless of
whether you’re manually generating the metadata file for plugin descrip
Hi Pavel,
[NOTE: I am cross-posting this to `dev@logging`, since I believe it is
more appropriate there]
On 29.11.2024 10:26, PavelTurk wrote:
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 poin
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.
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,
Hi Piotr,
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
plugi
Hi Pavel,
On 28.11.2024 15:47, PavelTurk wrote:
Hello everyone.
I am trying to create my own appender using JPMS service in
3.0.0-beta3. This is my code:
Apparently two small bugs made their way to `3.0.0-beta3`([1] and [2]),
which make compilation under JPMS challenging, but not impossibl
Hello everyone.
I am trying to create my own appender using JPMS service in 3.0.0-beta3. This
is my code:
import org.apache.logging.log4j.core.Appender;
import org.apache.logging.log4j.core.Filter;
import org.apache.logging.log4j.core.Layout;
import org.apache.logging.log4j.core.LogEvent;
impor
13 matches
Mail list logo
