Re: [Log4j] Header/footer and thread context

2017-11-30 Thread Remko Popma
Generally it doesn’t make sense to expect ThreadLocal lookups to work with async appender/loggers. Another lookup should be used. I haven’t looked at the code but I expect that the subject is cached somehow. Perhaps this should be changed (to no caching) so that the user experience is consiste

Re: [Log4j] Header/footer and thread context

2017-11-30 Thread Matt Sicker
I'm not sure if this use case makes much sense. Dynamic data like that makes more sense in the message itself, though I'm sure there are several ways to do this. On 30 November 2017 at 15:02, Mikael Ståldal wrote: > I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007 > > What is th

[Log4j] Header/footer and thread context

2017-11-30 Thread Mikael Ståldal
I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007 What is the expected behavior here? Should there be any thread context for header/footer? I guess it should be consistent for sync and async logging, which it isn't right now. But maybe the async case is correct in not includin

Re: [Log4j] Closing resolved JIRA issues

2017-11-30 Thread Ralph Goers
They should be automatically closed after a “reasonable” period of time. I’m not sure wha the definition of reasonable is. Ralph > On Nov 30, 2017, at 12:46 PM, Mikael Ståldal wrote: > > How should we handle closing of resolved JIRA issues? > > Idealy, the original reporter should close after

[Log4j] Closing resolved JIRA issues

2017-11-30 Thread Mikael Ståldal
How should we handle closing of resolved JIRA issues? Idealy, the original reporter should close after verifying, but quite often they never do. I usually close the resolved issues I am assigned to shortly after it is released. I just did with a bunch of issues released with 2.10.0.