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 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 default status logger level to WARN.
On Mon, Jan 22, 2024 at 2:34 PM Piotr P. Karwasz <piotr.karw...@gmail.com>
wrote:
> Hi Volkan,
>
> On Mon, 22 Jan 2024 at 13:31, Volkan Yazıcı <vol...@yazi.ci> 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? Or 1-2 occasional appearances?
>
> There are about 100 warnings in `log4j-core`. Most of them only occur
> if an error condition occurs, but it is fixed by the code.
> For example if a user has a properties configuration with a lot of
> unrecognized/ignored properties, a warning will be issued for each one
> of them.
>
> Some of these warnings are not fixable by the user, e.g. the "The
> bufferSize is set to {} but bufferedIo is false: {}" (bufferSize has
> always a value), but I am willing to go through the list of warnings
> and fix them.
>
> Piotr
>
