On 2016-10-21, Joe wrote: > From within DoAppend, there is a flag m_recursiveGuard which should > prevent re-entrancy problems from a synchronous appender's Append > method. For an asynchronous appender there would need to be an > additional check since it will want to log from a different thread.
We could store some kind of flag that acts like the recursive guard inside the (logical) thread context and then check for its existence inside the LoggingEvent's properties. > The following commit will give you an idea of what I'm thinking of: > https://github.com/apache/log4net/commit/9dc3ed9ae079d9abeacdf86c380b17efff4b3a97?w=1 > Is this something we should support? Your idea works for the case where you know you are logging from inside an appender. There is a different way an appender might receive messages that originate from itself when the appender uses a library that again uses log4net for logging. This wouldn't get caught by your approach but a property on the event would work. This is just an idea, nothing I've actually tried. > BTW if you look at the above commit without the ?w=1 suffix, you'll > see whitespace differences in the Flush method. I think the > .gitattributes file needs to add rules for converting spaces to tabs. Indentation inside the code base is a mess and I'm sure I've contributed to it by not using visual studio. Using .gitattributes could help if git was our primary SCM. For people using svn it wouldn't have any effect. Maybe we need somebody to configure VS with a "proper configuration" that we agree upon and re-indent the whole codebase once. Stefan
