logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: Logger setLevel?
Date Fri, 31 Jan 2014 21:33:17 GMT

On Jan 31, 2014, at 3:29 PM, Gary Gregory wrote:

> On Fri, Jan 31, 2014 at 2:00 PM, Nick Williams <nicholas@nicholaswilliams.net>
wrote:
> I do not think appenders should be in the API. Appenders are pretty much the definition
of an implementation detail.
> 
> As for setLevel, I absolutely think it's a problem point when migrating from Log4j 1
to Log4j 2. In my Log4j 1 apps, I offer a simple admin console for changing the log levels
of particular classes. This is MUCH harder to do in Log4j 2.
> 
> However, let's think carefully about what setLevel means. Based on the API documentation
for Log4j 1, I'm not ever sure anymore what setLevel does (I haven't looked at code). I /used/
to think it set the level for that logger AND any loggers that inherit from it. Now I'm not
sure.
> 
> So what's the use case? What might users need? Personally, I need to set the level for
that logger AND any loggers that inherit from it. But I most definitely see the use case for
setting the level ONLY for that logger. Perhaps we need setLevel and setAllLevels (or setDescendantLevel)
methods?
> 
> Agreed.
> 
> My use case is to support our admin UI. Our old simple console is has a set-all type
of setting. This is a brute force 'set all loggers to level X' setting. Our new console displays
a tree with all of the loggers available. There the obvious choice is to have a set level
for that node and its children. Like you, I can also imagine that users would want to only
set the one node and not the children. I'm not sure how much should be reflected in the API
though. In the UI that would be two menu items in the pop up: 'Set level' and 'Set level for
all'. In the API setLevel and setLevels would do but the names are so close... setLevel/setChildLevels?

setLevel and setLevelCascade?

> 
> Gary
>  
> 
> Nick
> 
> 
> On Jan 31, 2014, at 12:32 PM, Gary Gregory wrote:
> 
>> On Fri, Jan 31, 2014 at 1:13 PM, Scott Deboy <scott.deboy@gmail.com> wrote:
>> Re: appenders, I was thinking about Remko's response here:
>> 
>> http://stackoverflow.com/questions/21303746/migrating-from-log4j-1-2-to-log4j-2-how-to-get-list-of-all-appenders-and-rolli
>> 
>> I've picked the low-hanging fruits and given minIndex and maxIndex accessors.
>> 
>> Gary
>>  
>> 
>> 
>> On 1/31/14, Gary Gregory <garydgregory@gmail.com> wrote:
>> > On Fri, Jan 31, 2014 at 1:05 PM, Scott Deboy <scott.deboy@gmail.com> wrote:
>> >
>> >> Add setlevel. I also think appender belongs in Api. Yes?
>> >>
>> >
>> > Appenders are in the Core. That would be a big change.
>> >
>> > Another surprise: There is no Logger.getLevel().
>> >
>> > Gary
>> >
>> >
>> >> On Jan 31, 2014 10:01 AM, "Gary Gregory" <garydgregory@gmail.com>
wrote:
>> >>
>> >>> Porting from v1...
>> >>>
>> >>> We do not have Logger setLevel(Level) because it is not in the LCD API
>> >>> (Slf4j no, Logback yes, JUL yes).
>> >>>
>> >>> This sure makes it a pain to port from v1.
>> >>>
>> >>> What are the choices?
>> >>>
>> >>> - I hard code everything to the Core Logger API, possible if inflexible.
>> >>> - I add a util method that checks the Logger instance to see if it is
a
>> >>> Core Logger or if it is a Slf4j logger that wraps a logback logger?
>> >>> Bleh.
>> >>>
>> >>> Or, we can add setLevel and have it propagate the call down. Then we
can
>> >>> discuss whether a missing API in the underlying system means a noop
or
>> >>> an
>> >>> exception. Like JRE Collections do.
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Gary
>> >>>
>> >>> --
>> >>> 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
>> >>>
>> >>
>> >
>> >
>> > --
>> > 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
>> >
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


Mime
View raw message