I think Ralph is right: there should (could) be a limit on how often the user is informed but the user does need to be informed.
On Mon, Jan 3, 2022 at 8:32 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > I am in favor of limiting the recursion depth to a configurable with a > default number. > I fully expect virtually all normal usage would fall within the limits of > whatever we > would pick as the default. > > But should that limit be hit we can’t just return crap silently. It almost > certainly means > something bad is going on that the user needs to be informed of. We can > certainly use > something like ErrorHandler to limit the frequency the user is informed. > > Ralph > > > > On Jan 3, 2022, at 5:41 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > There is a PR <https://github.com/apache/logging-log4j2/pull/644> for > this > > issue, shall we bring this to a conclusion? > > > > I am in favor of this PR if the following changes were implemented: > > - limit is read from a property > > - limit is documented > > - stay quiet (i.e., not StatusLogger exception logging) if the limit has > > been exceeded > > > > My rationale for the "stay quiet" feature is that, if the runtime > exhibits > > a behavior not anticipated by the configuration, rather than nuking the > > StatusLogger, simply practice the configuration: recurse no more. > > > > This said, I am struggling to not get drawn into Carter's following > > remark: *"I'm > > not sure I entirely understand what we're protecting against – I'd > consider > > any recursion beyond what the configuration author expects to be an > > incredibly serious problem"*. > > > > Note that I am not strongly opinionated about the feature per se. I just > > want to bring the discussion to a conclusion. If we decide to reject the > PR > > (preferably, with a good argument), that is fine by me too. > >
