Hm... what about: org.apache.logging.log4j.core.Filter.filter(Logger, Level, Marker, Message, Throwable) org.apache.logging.log4j.core.Filter.filter(Logger, Level, Marker, Object, Throwable) org.apache.logging.log4j.core.Filter.filter(Logger, Level, Marker, String, Object...)
These are not given a log event. Gary On Tue, Jan 19, 2016 at 12:18 PM, Gary Gregory <[email protected]> wrote: > [I hit 'Send' by mistake!] > > Hi Francis, > > It sounds like POB (Plain Old Bug) to me. Can you create a JIRA and attach > a diff file please? > > We should also look at all the call sites for ThreadContext.get(String) > and readers of ThreadContext in general. > > Francis, if you can give a scan for similar ThreadContext issues, I would > greatly appreciate it. > > Thank you! > Gary > > On Tue, Jan 19, 2016 at 12:15 PM, Gary Gregory <[email protected]> > wrote: > >> Sounds like POB (Plain Old Bug). Can you create a JIRA and attach a diff >> file please? >> >> >> On Tue, Jan 19, 2016 at 11:51 AM, Francis Lalonde <[email protected] >> > wrote: >> >>> Hello Log4J users, >>> >>> I am using Log4J 2.5 with AsyncLogger mode enabled. I am trying to >>> filter events at the Appender level using DynamicThresholdFilter but it is >>> not working. >>> >>> I believe this is because the filter is basing its decision on the >>> ThreadContext even though it is filtering an asynchronous event on a worker >>> thread : >>> >>> private Result filter(final Level level) { >>> final Object value = ThreadContext.get(key); // always returns >>> null, ThreadContext is empty on disruptor thread >>> if (value != null) { >>> ... >>> >>> I fixed the DynamicThresholdFilter to use the context from the log event >>> instead, and it gave me the expected filtering behavior : >>> >>> private Result filter(final Level level, Map<String, String> >>> context) { >>> final Object value = context.get(key); >>> if (value != null) { >>> ... >>> >>> public Result filter(final LogEvent event) { >>> return filter(event.getLevel(), event.getContextMap()); >>> } >>> >>> public Result filter(final Logger logger, final Level level, final >>> Marker marker, final Message msg, >>> final Throwable t) { >>> return filter(level, ThreadContext.getContext()); >>> } >>> >>> ThreadContextMapFilter is built the same way. Unless I am mistaken and >>> forgot some basic tenement of log4j usage, this make these Filters useless >>> in async mode elsewhere than Context-wide. >>> >>> Should I keep on using my fixed version of the Filter or should I >>> submit a tentative fix? If so, please tell me what is the procedure to do >>> so. >>> >>> Thank you, >>> >>> Francis >>> >>> >>> >>> >>> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
