[slf4j-dev] Re: TRACE level

[Ceki Gülcü]

At 04:18 AM 7/5/2005, Niclas Hedhman wrote:
>On Tuesday 05 July 2005 03:57, Ceki Gülcü wrote:
> > So, wdyt?
>
>At first I am undecided. Somehow it feels very similar to what we did in
>LogKit as well as Avalon Logging API, but still not.

What is similar in LogKit or Avalon Logging API? I was not aware of
any functionality similar to Markers in Logkit or Avalon Logging
API. Do you have a method name? A URL? Or maybe you just meant that
marker functionality can be achieved by using child loggers?

>Why not use child loggers instead? Direct comparison;

That's an excellent question. More below.

>class HttpRequest {
>
>    Logger mainLogger = LoggerFactory.getLogger(HttpRequest.class);
>    Logger headerLogger = mainLogger.addChildLogger( "headers" );
>
>    void doRequest()
>    {
>        mainLogger.debug("Request URI is {}", uri);
>
>        headerLogger.debug( "Headers follow." );
>        for(int i = 0; i < header.length; i++)
>        {
>            headerLogger.debug( "{}: {}", header[i].getName(),
>header[i].getValue());
>        }
>
>        ... do real work
>    }
>}
>
>
>Automatically get the composite, less method signatures, more leverage on the
>rest of the logging framework. Less overhead ? Less "adaption" ?


Yes, there are important advantages: less method signatures, leverage
of existing framework(s), possibly less overhead. (I don't see how you
get composite though.) Child loggers provide significant expressive
power without introducing new concepts or needing to change the
framework. (Is that what you call "adaption"?)  Anyway, leveraging the
existent is a convincing argument to be reckoned with.

However, markers allow us to mark *any* logger. So, if a concern cuts
across many loggers, you can mark their statements with one
marker. Compare that with the child logger approach where you would
need as many "header" children as loggers.

Consider the "ignore" or "no_stack_trace" marker which is potentially
applicable in any context. With markers you are using a distinct
element to specialize a log statement. With child loggers, the
specialization is encoded within the logger name. In the "ignore" case,
the fact that a child logger is a fully-fledged logger does not help
because (I am assuming) the child logger is likely to inherit its
level and appenders from its parent. It will only differ in its name,
i.e. the ".header" suffix.

Nevertheless, I very much agree with you that any new approach has to
present tangible and clear advantages over existing functionality
already offered by logging frameworks. It is not yet clear whether
markers offer decisive advantages or not. In particular, markers
(applicable to multiple loggers) need to be easy to configure.


>Cheers
>Niclas

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/