On Fri, Dec 5, 2014 at 11:14 AM, Ralph Goers <[email protected]>
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.
>
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 <[email protected]> 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: [email protected] | [email protected]
> 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: [email protected] | [email protected]
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
