logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Duane <nic...@msn.com>
Subject RE: approach for defining loggers
Date Sat, 12 Sep 2015 00:12:48 GMT
I am a bit confused now.  Previously someone said that if we used markers the level used in
the log statement would be irrelevant.  However, based on this thread it looks like that's
not the case.  Can someone give a definitive answer on what determines whether an event makes
it to an appender?

Thanks,
Nick

> Date: Fri, 11 Sep 2015 16:46:14 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
> 
> On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers <ralph.goers@dslextreme.com>
> wrote:
> 
> >
> > > On Sep 11, 2015, at 3:50 PM, Gary Gregory <garydgregory@gmail.com>
> > wrote:
> > >
> > >
> > > This updated text I hope will help:
> > >
> > > "No new loggers needed, just an additional parameter to your log call,
> > > <em>regardless</em> of the level API used.
> > >
> > > Now, I can configure Log4j to log only events that contain the marker
> > DOOR
> > > (if that level is enabled).”
> >
> > This isn’t necessarily true.  If you have a global filter that accepts the
> > event then the log level of the appropriate logger will not be checked.
> > However, other filters on the AppenderRef and Appenders will still be
> > checked.
> >
> 
> Hm, OK, but I am not sure I want to make that part of the article more
> complicated. I could say "if that level is enabled and a global filter did
> not accepts the event".
> 
> Gary
> 
> >
> > Ralph
> >
> >
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message