Re: [log4j] Bump default status logger level to WARN

Piotr, could you share some examples of typical working configurations that will start reporting errors? What kind of errors will these reports contain? A message or a fully-blown stack trace? Will there be a multitude of these? Or 1-2 occasional appearances? I know answers will vary dependending

Re: [log4j] Bump default status logger level to WARN

Hi Volkan, On Mon, 22 Jan 2024 at 13:31, Volkan Yazıcı wrote: > Piotr, could you share some examples of typical working configurations that > will start reporting errors? What kind of errors will these reports > contain? A message or a fully-blown stack trace? Will there be a multitude > of these

Re: [log4j] Bump default status logger level to WARN

I am in favor of reporting unrecognized/ignored properties, otherwise there is no incentive for users to fix their configurations. Those who don't want to be bothered with them, can still do so via `-Dlog4j.StatusLogger.level=off`. Shall we mention this issue (that is, ineffective configurations a

Re: [log4j] Bump default status logger level to WARN

Hi Volkan, On Mon, 22 Jan 2024 at 15:15, Volkan Yazıcı wrote: > Shall we mention this issue (that is, ineffective configurations as the one > you shared about `bufferSize`-vs-`bufferedIo`) to Łukasz and see if he > would be willing to carry out that clean up? ... granted PMC agrees to > raise the

Re: [RESULT] Making Log4j 2 API "the Log4j API"

There was also the idea that if we introduce some form of a v3 API, it’ll be alongside the existing v2 API, not a breaking change. > On Jan 21, 2024, at 1:32 PM, Volkan Yazıcı wrote: > > *Abstract:* There will not be a Log4j 3 API. Both Log4j 2 and Log4j 3 will > implement the Log4j 2 API. > >

Re: interesting writeup of some nice engineering

I’m not sure if it’s a binary layout, but OpenTelemetry does define some standard formats and protocols around transferring and collecting log data. Any sort of binary layout would require some level of tooling support to be useful. > On Jan 19, 2024, at 3:12 AM, Volkan Yazıcı wrote: > > I kne

Re: [log4j] Bump default status logger level to WARN

I like this idea, Piotr. > On Jan 22, 2024, at 12:28 PM, Piotr P. Karwasz > wrote: > > Hi Volkan, > > On Mon, 22 Jan 2024 at 15:15, Volkan Yazıcı wrote: >> Shall we mention this issue (that is, ineffective configurations as the one >> you shared about `bufferSize`-vs-`bufferedIo`) to Łukasz a

Re: [RESULT] Making Log4j 2 API "the Log4j API"

Hi Matt, On Mon, 22 Jan 2024 at 19:35, Matt Sicker wrote: > > There was also the idea that if we introduce some form of a v3 API, it’ll be > alongside the existing v2 API, not a breaking change. Yes, that idea has also a PoC: https://github.com/apache/logging-log4j2/pull/2215 However right now