I was thinking about this the other day in the following terms: How would a user or dev know that something went wrong?
Let's say I load a config and I see the logging is incorrect in some way. Under the covers, it's because recursion hit a limit. So how can a user or dev know they need to enable recursion or raise its limit? At the lowest level, when replace() is called and the recurse limit is hit, what would be the best outcome? I claim, from worst to best: - A String that is partially replaced where replacement stopped when the recursion limit was hit. - The original String, no replacement took place. - null, indicating something is clearly broken. Aside from the above, I do not see how we can help user and devs _without_ logging to the status logger. I am thinking about this from a support perspective. WDYT? Gary (AFK for the rest of the work day) On Mon, Jan 3, 2022 at 7:41 AM Volkan Yazıcı <[email protected]> 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. >
