Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 55E641097E for ; Fri, 31 Jan 2014 21:43:57 +0000 (UTC) Received: (qmail 97471 invoked by uid 500); 31 Jan 2014 21:43:56 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 97358 invoked by uid 500); 31 Jan 2014 21:43:56 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 97349 invoked by uid 99); 31 Jan 2014 21:43:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 21:43:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of garydgregory@gmail.com designates 209.85.214.41 as permitted sender) Received: from [209.85.214.41] (HELO mail-bk0-f41.google.com) (209.85.214.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 21:43:50 +0000 Received: by mail-bk0-f41.google.com with SMTP id na10so2377604bkb.0 for ; Fri, 31 Jan 2014 13:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IKKL0oIQgRHRBN0Y8uGH/td8avGNwm3PeqW2YfQPS5A=; b=TVUc7lXuQB3XJjN9Yu3EdVaAXFZqOWsAIs3Up0OzAtjt7W38mn6/QooBEH+gmm/uev 8Dpdt/Hgmj/a5aXL9+DdhJQJgrmtOYTNR6nd8XXWYGEd1TXXVhX/pR1mQ3G0rx0IsUHT AIebGtm94sfc5VEJCohiW+JNKbVr0sC9yeYhGHwt3ZX6BgwUsZ/Ld4gkrQBC9cjOVzwt dqE/Fy2DABBBOzFKN1pH94aTg5+HeNNPGmeG07UqfBcqaXLgAt9MugDsNIOrfq6Gg5D1 iJOZSBzuygIMo7df+ysLF1Zuzz08dHjXjxi+PSt4Yk2/0tEyJRR5BrY4SG/uK3WofURE vJHA== MIME-Version: 1.0 X-Received: by 10.204.56.69 with SMTP id x5mr15278bkg.115.1391204609748; Fri, 31 Jan 2014 13:43:29 -0800 (PST) Received: by 10.204.102.201 with HTTP; Fri, 31 Jan 2014 13:43:29 -0800 (PST) In-Reply-To: <3778AEAE-C10D-4B3E-B550-BDDB9EF59BCB@nicholaswilliams.net> References: <84AD151F-12F5-45C5-8AA0-FFFD003615DC@nicholaswilliams.net> <3778AEAE-C10D-4B3E-B550-BDDB9EF59BCB@nicholaswilliams.net> Date: Fri, 31 Jan 2014 16:43:29 -0500 Message-ID: Subject: Re: Logger setLevel? From: Gary Gregory To: Log4J Developers List Content-Type: multipart/alternative; boundary=001a11c376a0931fb104f14b10fd X-Virus-Checked: Checked by ClamAV on apache.org --001a11c376a0931fb104f14b10fd Content-Type: text/plain; charset=UTF-8 On Fri, Jan 31, 2014 at 4:33 PM, Nick Williams < nicholas@nicholaswilliams.net> wrote: > > 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? > Or, just overload the name. setLevel(Level) and setLevel(Level, boolean)? The admin UI would send the set level request and the server would call setLevel(Level, boolean). setLevel would default to setLevel(Level, true) which would be cascade. Gary > > > Gary > > >> >> Nick >> >> >> On Jan 31, 2014, at 12:32 PM, Gary Gregory wrote: >> >> On Fri, Jan 31, 2014 at 1:13 PM, Scott Deboy 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 wrote: >>> > On Fri, Jan 31, 2014 at 1:05 PM, Scott Deboy >>> 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" >>> 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 >>> >>> 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 >>> > >>> >>> --------------------------------------------------------------------- >>> 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 > > > -- 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 --001a11c376a0931fb104f14b10fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 31, 2014 at 4:33 PM, Nick Williams <nicholas@nicholasw= illiams.net> wrote:

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 defini= tion 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 simp= le 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 an= ymore 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? Pers= onally, I need to set the level for that logger AND any loggers that inheri= t from it. But I most definitely see the use case for setting the level ONL= Y for that logger. Perhaps we need setLevel and setAllLevels (or setDescend= antLevel) methods?

Agreed.

My use cas= e 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' sett= ing. Our new console displays a tree with all of the loggers available. The= re 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 no= de and not the children. I'm not sure how much should be reflected in t= he API though. In the UI that would be two menu items in the pop up: 'S= et level' and 'Set level for all'. In the API setLevel and setL= evels would do but the names are so close... setLevel/setChildLevels?

setLevel and setL= evelCascade?

Or, just overload = the name.

setLevel(Level) and setLevel(Level, boolean)?
The admin UI would send the set level request and the server= would call setLevel(Level, boolean). setLevel would default to setLevel(Le= vel, true) which would be cascade.

Gary
=C2=A0


Gary
=C2=A0

Nick


On Jan 31, 2014, at 12:32 PM, Gary Grego= ry wrote:

On Fri, Jan 31, 2014 = at 1:13 PM, Scott Deboy <scott.deboy@gmail.com> wrote:
Re: appenders, I was thinking about Remko= 9;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
=C2=A0


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:<= br> >
>> 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 i= nflexible.
>>> - I add a util method that checks the Logger instance to see i= f it is a
>>> Core Logger or if it is a Slf4j logger that wraps a logback lo= gger?
>>> Bleh.
>>>
>>> Or, we can add setLevel and have it propagate the call down. T= hen 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/&g= t;
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: ht= tp://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>
>
> --
> E-Mail: ga= rydgregory@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/>
---------------------------------------------------------------------=
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org




--



--




--
--001a11c376a0931fb104f14b10fd--