Okay, nested logging is officially not supported. I will remove the nested logging tests blocking the `2.x-StatusLogger-revamp` branch.
What about the other two issues I mentioned: 1. `log4j2.formatMsgAsync` and `@AsynchronouslyFormattable` don't always work (`log4j2.formatMsgAsync=false` is ignored for reusable messages, which are formatted always eagerly) 2. Usage of `Message#getFormattedMessage()` in `InternalAsyncUtil.makeMessageImmutable()` triggers an unnecessary `String` allocation On Mon, Feb 5, 2024 at 4:29 PM Ralph Goers <rgo...@apache.org> wrote: > > > On 2024/02/05 15:17:29 Volkan Yazıcı wrote: > > > > AFAIK, nested logging is not a documented feature. Yet one can find > several > > tickets people has filed issues that were fixed by us. Hence, it is safe > to > > conclude that it is used. > > You are correct that it is not documented. Nor should it be. As you are > seeing you cannot count on how it will behave. I believe any unit tests > that expect a particular behavior should be removed. > > > > > I also don't know why recursion is not allowed in `AppenderControl`. > > (Related history is too old and could not get in while migrating from SVN > > to Git.) > > Recursion is not allowed because it creates a stack overflow exception. > For example, The user logs a message that routes to an Appender that uses a > framework that logs a message. That message gets routed back to the same > Appender which again calls the same framework which logs a message. This > will endlessly repeat. The recursion check prevents this from happening and > the nested log message is discarded. This is actually the ONLY behavior of > nested logging that should be documented and guaranteed. Passing objects to > logging that themselves perform logging as they are formatted has to result > in the unpredictable category since the formatting cannot be guaranteed to > occur the same way under all conditions. > > Ralph >
