Hi Mikael,
On Sun, 7 Jan 2024 at 10:38, Mikael Ståldal wrote:
> What about (re)moving the classes which actually depends on Jackson
> (AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser,
> YamlLogEventParser), but keeping the interfaces (LogEventParser,
> TextLogEventParser, Par
Then users or 3rd parties can implement their own parsers if they need to.
It might be useful to have parsers for some common formats like GELF,
Logstash or RFC-5424, and that can be implemented without using Jackson
if necessary.
/Mikael
On 2024-01-07 10:38, Mikael Ståldal wrote:
What abou
What about (re)moving the classes which actually depends on Jackson
(AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser,
YamlLogEventParser), but keeping the interfaces (LogEventParser,
TextLogEventParser, ParseException) in log4j-core?
/Mikael
On 2024-01-05 11:25, Volkan Y
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
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
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
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
Yeah - Given that ticket it is obvious to me that this class should be moved to
another module. I don’t think moving it to Chainsaw or Flume is the correct
thing to do. For now, I would put it into log4j-samples, either under
log4j-server or in its own module.
Note that a Flume event consists
Hi Ralph,
On Tue, 2 Jan 2024 at 13:21, Ralph Goers wrote:
>
> Why is it included if it isn’t used?
Apparently this was added by Mikael in:
https://issues.apache.org/jira/browse/LOG4J2-1986
There were no significant changes/bug fixes after the initial submission.
Piotr
Why is it included if it isn’t used?
Ralph
> On Jan 2, 2024, at 4:09 AM, Piotr P. Karwasz wrote:
>
> Hi,
>
> 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 remo
Hi,
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 somewhere else (Chainsaw
or Flume?).
My main concern is vulnerability
11 matches
Mail list logo
