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 037EE10037 for ; Fri, 5 Dec 2014 16:54:04 +0000 (UTC) Received: (qmail 1439 invoked by uid 500); 5 Dec 2014 16:54:03 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 1387 invoked by uid 500); 5 Dec 2014 16:54:03 -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 1377 invoked by uid 99); 5 Dec 2014 16:54:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Dec 2014 16:54:03 +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.212.169 as permitted sender) Received: from [209.85.212.169] (HELO mail-wi0-f169.google.com) (209.85.212.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Dec 2014 16:53:38 +0000 Received: by mail-wi0-f169.google.com with SMTP id r20so1978786wiv.2 for ; Fri, 05 Dec 2014 08:52:07 -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=Kdz0P249F+E6rYeUooak8Zv2dw2SdALLhLOtH1G9lQs=; b=EprVLyfJ/Z9bboAv62YUpS4OtUNqO5D56iWjGRtWGLi44RT42DsJju+FF7EfH3hmD5 DxzBENvSfdnhcbvcgbI2A6lHjGXvwjIeGo9Zl7A5ymb8ifPwkCiJ2um9jvpeql4q/1Vo 4RyEnNQgzb3EFpv+R410M3swF0gb4PTnjuCtpuWgSj4A43V+rlJ3y7EXUXWNPuf2mA1f Mu5iUMofdVoyYTmOIJ8gAnv1Yr3Fkq3GcHXV89qa8t5SyYBmH7BS2me/jUHVeQ7K6N1E cx719GC8d2FdsQE75Ny7DOGhibmgRSXr/AWuGaUuGbfzdkBuR0b/yDBAhMi5MIGjBapl leNg== MIME-Version: 1.0 X-Received: by 10.180.85.34 with SMTP id e2mr5669198wiz.0.1417798327387; Fri, 05 Dec 2014 08:52:07 -0800 (PST) Received: by 10.27.13.29 with HTTP; Fri, 5 Dec 2014 08:52:07 -0800 (PST) In-Reply-To: References: <2A60EBA4-A925-4663-97B4-BAF9FEF7A71E@dslextreme.com> Date: Fri, 5 Dec 2014 11:52:07 -0500 Message-ID: Subject: Re: Less crowded Logger API design... From: Gary Gregory To: Log4J Developers List Content-Type: multipart/alternative; boundary=f46d04428712aacd9805097ae59d X-Virus-Checked: Checked by ClamAV on apache.org --f46d04428712aacd9805097ae59d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 5, 2014 at 11:41 AM, Gary Gregory wrote: > On Fri, Dec 5, 2014 at 11:14 AM, Ralph Goers > wrote: > >> I think I would find this confusing. There are already a set of >> logger.trace, logger.debug, etc methods that take arguments. Having a s= et >> of trace, debug, etc methods that don=E2=80=99t have args but accept a l= og method >> would mean that people might code logger.trace(=E2=80=9CThis {} and that= {}=E2=80=9D, this, >> that); when they meant to code logger.trace().log(=E2=80=9CThis {} and t= hat {}=E2=80=9D, >> this, that);. Furthermore, they might have coded >> >> logger.trace().log(=E2=80=9CThis {}, that {}, the other {}=E2=80=9D, thi= s, that, other); >> >> and then later change it to >> >> logger.trace().log(=E2=80=9CThis {}, that {}, the other {}, whatever {}= =E2=80=9D, this, >> that, other, whatever); >> >> Which essentially means that the log method has to support all the >> variations that are already in the API. >> >> I do see the advantage that each of the trace(), debug(), etc methods ca= n >> return an interface that has all the log methods, but I don=E2=80=99t li= ke the idea >> of having both API formats. >> > Maybe something like this then: http://pastebin.com/vQdmWUBD Maybe Logger and LevelLogger could have a common super interface. Gary > > OK, so back to the original issue while I keep experimenting. Would you b= e > OK with adding to the Logger API: > > void info(Marker marker, String message, Object arg0); > void info(Marker marker, String message, Object arg0, Object arg1); > void info(Marker marker, String message, Object arg0, Object arg1, Object > arg2); > > and so on? > > Gary > > >> Ralph >> >> >> On Dec 5, 2014, at 8:08 AM, Gary Gregory wrote: >> >> Hi All: >> >> I've thinking about adding 1, 2 and 3 arg variants to the Object... >> methods in Logger to avoid paying the cost of creating Object arrays. Th= is >> is especially important when no logging takes place and I have a call li= ke >> >> logger.trace("this {} and that {}", this, that); >> logger.debug("this {} and that {}", this, that); >> >> But the idea of adding 3 extra method times the number of log levels is >> not appealing. >> >> So that go me to consider this call side pattern: >> >> logger.trace.log.("this {} and that {}", this, that); >> logger.debug.log("this {} and that {}", this, that); >> >> where trace could be "trace()" a method, or "trace" a public ivar. >> >> Obviously, this would eliminate the need to duplicate method patterns fo= r >> each level when we want new APIs. >> >> 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 > --=20 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 --f46d04428712aacd9805097ae59d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 5, 2014 at 11:41 AM, Gary Gregory <garydgregory@gmail.com= > wrote:
On Fri, Dec 5, 2014 at 11:14 AM, Ralph Goers &l= t;ralph.goe= rs@dslextreme.com> wrote:
I think I would = find this confusing.=C2=A0 There are already a set of logger.trace, logger.= debug, etc methods that take arguments.=C2=A0 Having a set of trace, debug,= etc methods that don=E2=80=99t have args but accept a log method would mea= n that people might code logger.trace(=E2=80=9CThis {} and that{}=E2=80=9D,= this, that); when they meant to code logger.trace().log(=E2=80=9CThis {} a= nd that {}=E2=80=9D, this, that);.=C2=A0 Furthermore, they might have coded= =C2=A0

logger.trace().log(=E2=80=9CThis {}, that {= }, the other {}=E2=80=9D, this, that, other);=C2=A0

and then later change it to

logger.trace().log(= =E2=80=9CThis {}, that {}, the other {}, whatever {}=E2=80=9D, this, that, = other, whatever);

Which essentially means that the= log method has to support all the variations that are already in the API.= =C2=A0

I do see the advantage that each of the tra= ce(), debug(), etc methods can return an interface that has all the log met= hods, but I don=E2=80=99t like the idea of having both API formats.

= Maybe something like this then:

http://pastebin.com/vQdmWUBD

Maybe Logger and Le= velLogger could have a common super interface.

Gary

OK, so back to the original issue while I keep experimenting. Woul= d you be OK with adding to the Logger API:

void info(Marker marker, String message, Object arg0);
void info= (Marker marker, String message, Object arg0, Object arg1);
=
void info(Mar= ker marker, String message, Object arg0, Object arg1, Object arg2);

and so on?<= span class=3D"">

=
Gary

=

Ralph
<= /font>


On Dec 5, 2014, at 8:08 AM, Gary Gregory <garydgregory@gmail.com> wrote:
Hi All:

I've thinking about adding 1, 2 and 3 arg variants to the Object... = methods in Logger to avoid paying the cost of creating Object arrays. This = is especially important when no logging takes place and I have a call like =

logger.trace("this {} and that {}", this, that);logger.debug("this {} and that {}", this, that);

Bu= t the idea of adding 3 extra method times the number of log levels is not a= ppealing.

So that go me to consider this call side pattern:

l= ogger.trace.log.("this {} and that {}", this, that);
logger.de= bug.log("this {} and that {}", this, that);

where tr= ace could be "trace()" a method, or "trace" a public iv= ar.

Obviously, this would eliminate the need to duplicate= method patterns for each level when we want new APIs.

Thought= s?

Gary




--
--f46d04428712aacd9805097ae59d--