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: [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: [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 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

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

Discussions on PRs or issues would be easier to continue if the same mailing lists weren’t already spammed by Dependabot. > On Aug 7, 2023, at 1:08 PM, Ralph Goers wrote: > > I commented on the PR. It seems odd that the discussion is continuing on the > dev list instead of the PR, but OK. > >

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

I commented on the PR. It seems odd that the discussion is continuing on the dev list instead of the PR, but OK. The PR reports a problem with a specific condition that is essentially logging at the wrong log level. It proposes a fix of changing the default log level. I see no need to do that.

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

We could always use markers for certain events, and then the default config could output those. > On Aug 6, 2023, at 1:41 AM, Lukasz S. wrote: > > Hi, > > Just wanted to sum up proposed solutions and introduce new one: > > 1) Implemented default logger level change from ERROR to WARN (dislike

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

Hi, Just wanted to sum up proposed solutions and introduce new one: 1) Implemented default logger level change from ERROR to WARN (disliked by Ralph and Gary) 2) logging an ERROR instead when JSON or YAML configuration is found but dependencies are missing (proposed by Ralph) and thought of sth

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

One think that turns me off big time about slf4j is that it logs to the console a warning about binding jars, almost always, in large apps (it does not matter why). Let's not do that if there is a chance it will annoy users. Gary On Wed, Jul 26, 2023, 06:14 Piotr P. Karwasz wrote: > Hi all, > >

[log4j] Bump default status logger level to WARN

Hi all, In [1] Łukasz implemented the long-awaited bump of the default status logger level from ERROR to WARN. >From my perspective this is a good change, since most configuration errors can be caught without setting `-Dlog4j2.debug=true`. On the other hand some users will complain that "working"