Hi all,
Matt made an interesting proposal to use JSpecify nullability
annotations in Log4j:
https://github.com/apache/logging-parent/issues/88
I am a big fan of nullability annotations but in my professional
experience they are worthless, unless the whole team agrees to use
them and how to intro
If this is a runtime dependency then I am against using it in Log4J api and
core.
Ralph
> On Jan 2, 2024, at 3:17 AM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Matt made an interesting proposal to use JSpecify nullability
> annotations in Log4j:
>
> https://github.com/apache/logging-parent/is
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
Hi Ralph,
On Tue, 2 Jan 2024 at 11:59, Apache wrote:
>
> If this is a runtime dependency then I am against using it in Log4J api and
> core.
It is an annotation-only library, with a retention of `RUNTIME`.
However annotations should not cause `NoClassDefFoundError`s.
Piotr
On Tue, Jan 2, 2024 at 1:00 PM Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Tue, 2 Jan 2024 at 11:59, Apache wrote:
> >
> > If this is a runtime dependency then I am against using it in Log4J api and
> > core.
>
> It is an annotation-only library, with a retention of `RUNTIME`.
> However annotat
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
Nullability annotations are trivial to remove. I’ve added some basic aliases
for them in main. As it stands, they’re copies of the four JSpecify annotations
with those annotations applied to them along with equivalent JSR 305
meta-annotations to make the annotations function the same in existing
Thanks for fixing this. This formatting change got swept up in a branch of mine
you already reviewed.
> On Jan 2, 2024, at 10:10 AM, pkarw...@apache.org wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> pkarwasz pushed a commit to branch main
> in repository htt
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
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
10 matches
Mail list logo
