logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Less crowded Logger API design...
Date Fri, 05 Dec 2014 16:52:07 GMT
On Fri, Dec 5, 2014 at 11:41 AM, Gary Gregory <garydgregory@gmail.com>
wrote:

> On Fri, Dec 5, 2014 at 11:14 AM, Ralph Goers <ralph.goers@dslextreme.com>
> 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 set
>> of trace, debug, etc methods that don’t have args but accept a log method
>> would mean that people might code logger.trace(“This {} and that{}”, this,
>> that); when they meant to code logger.trace().log(“This {} and that {}”,
>> this, that);.  Furthermore, they might have coded
>>
>> logger.trace().log(“This {}, that {}, the other {}”, this, that, other);
>>
>> and then later change it to
>>
>> logger.trace().log(“This {}, that {}, the other {}, whatever {}”, 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 can
>> return an interface that has all the log methods, but I don’t like 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 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(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 <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);
>>
>> 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 for
>> each level when we want new APIs.
>>
>> 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
>



-- 
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
View raw message