Re: `a.o.l.l.core.parser` package removal

2024-01-05 Thread Piotr P. Karwasz
Hi, On Tue, 2 Jan 2024 at 12:08, Piotr P. Karwasz wrote: > While working on PR#2142[1] I noticed that we have an > `a.o.l.l.core.parser` package that depends on Jackson. > > Since Log4j itself never parses log events, I would propose to remove > it from `log4j-core` and optionally move it somewhe

Re: `a.o.l.l.core.parser` package removal

2024-01-05 Thread Volkan Yazıcı
I support the idea of removing the Jackson-based `LogEvent` parser. Back in the days when `JsonLayout` was the only JSON-formatted layout, it might have made sense to provide deserialization support next to serialization. With `JsonTemplateLayout`, where the JSON structure is controlled by the user

Re: (logging-log4j2) 01/02: Delete generated module descriptors before recompilation

2024-01-05 Thread Volkan Yazıcı
> A previous `generate-module-descriptors` execution leaves > `target/classes/module-info.class` files. These interfere with > the way the `maven-compiler-plugin` works. Piotr, could you elaborate on this interference? What exactly is the problem we are trying to address here? I have the impressi

Re: `a.o.l.l.core.parser` package removal

2024-01-05 Thread Piotr P. Karwasz
Hi Volkan, On Fri, 5 Jan 2024 at 11:25, Volkan Yazıcı wrote: > @Piotr, do you propose removing it in `2.x` or `main`? My preference would > be both. Unfortunately we never marked it as an internal package, so this would break binary compatibility. We should deprecate it in 2.23.0, together with

Re: (logging-log4j2) 01/02: Delete generated module descriptors before recompilation

2024-01-05 Thread Piotr P. Karwasz
Hi Volkan, On Fri, 5 Jan 2024 at 11:30, Volkan Yazıcı wrote: > > > A previous `generate-module-descriptors` execution leaves > > `target/classes/module-info.class` files. These interfere with > > the way the `maven-compiler-plugin` works. > > Piotr, could you elaborate on this interference? What

Re: `a.o.l.l.core.parser` package removal

2024-01-05 Thread Volkan Yazıcı
I understand your compatibility concerns, but we are not bound by it. For instance, in `2.22.0`, we removed `FastDateParser`, which was public too. If I am not mistaken, `LogEventParser` is not documented anywhere. All in all, I am fine with either removing or deprecating it. On Fri, Jan 5, 2024

Re: PropertyKey abstraction

2024-01-05 Thread Volkan Yazıcı
I agree with all points Piotr raises. I am in favor of reverting back to the system we have in `2.x`, because the new property system has more disadvantages than benefits in its current state and it hinders the ongoing operation of sync'ing `2.x` and `main`, and generating API docs from sources. R