[slf4j-dev] Beta 4 and the new method signatures

[Niclas Hedhman]

On Thursday 07 July 2005 13:54, Christian Stein wrote:
> I'm totally with Niklas - especially in two issues. First the strong typing
> of the 'message' and 'format' argument as String. And second, his proposal
> of the generic 'log(LEVEL, message...)' methods.

Huh??
Have I proposed that?

If you are referring to;
<quote>
If 
   logger.debug( m )
is the equivalent of 
   logger.log( Level.DEBUG, m );
and you are now introducing
   logger.log( Level.DEBUG, Marker.MINE, m );
</quote>

then it was just a matter of visualizing that there is multi-dimensional axes 
in Ceki's proposal, and as (I think) Endre pointed out the Logger instance 
itself was yet another.

- o - o - o - o - o -

After reviewing the ideas and experiences of others, especially Endre and 
Greg, I am starting to get convinced that the the whole issue is tackled the 
wrong way. "Wrong" as in another evolutionary step down the dinosaur path, 
and not an emergent mammal takeover lurking in the shadows ;o) (please take 
the joke for what it is...)

Instead of exposing these multi-dimensional concerns, which may 'never end', I 
think that there is simply just a need for better management at the 
implementation side of things.

I could classify two (dinosaur and mammal) trains of thoughts as;

 1. The "business logic" programmer is fairly well aware of what is relevant 
logging material, and that he/she makes the decisions "this is info and that 
is debug". The deployment team should most of the time just enable "debug", 
"info" and so forth for most of the application and get "reasonable" output. 
This is "standard logging thinking", the norm of the day.

 2. The "business logic" programmer is not capable of knowing how the logging 
data is going to be consumed, and a library having a "info" statement could 
in some applications be considered "debug" and annoying. One could defer the 
definition of the logging output until deploy-time (provided the tools 
existed). The axes of concerns could be assigned totally outside the API 
itself. Let me elaborate;


public interface Logger
{
    String getName();

    boolean isEnabled();
    void log( String message );
    void log( Throwable throwable );
    void log( String message, Throwable throwable );
    void log( String format, Object arg );
    void log( String format, Object arg1, Object arg2 );

    Logger addChildLogger( String name );
}

If the "business logic code" seriously think the user needs more than one 
aspect of the output, then create more Loggers, and good practices would 
possibly go towards 'children according to function', instead of towards 
'verbosity'. But that may not be feasible.

Much later (especially for libraries and other code that is heavily re-used) 
one, two or more axes are created and each of the Loggers are assigned to 
zero, one or more axes.

public interface Axis  // better name sure can found
{
    String getName();

    Object getCurrent();                 // perhaps limit to Comparable
    void setCurrent( Object current );

    void assignLogger( Logger logger, Object argument );
    void unassignLogger( Logger logger );

    void addTarget( Target target );       // Appender in Log4J terminology
    void removeTarget( Target target );
}

So, I could(!) create one Axis for the equivalent of "Level", where "Current" 
is one of the discussed method levels; "fatal", "error", "warning", "info", 
"debug", "trace". And that when the Logger is assigned to the Axis, its Level 
is given as an argument. You want 45 level granularity, be my guest. And the 
single levelAxis.setCurrent( "debug" ) could set the entire application in 
debug mode, or parts of the application in debug mode. See my point??

I can create the the "Ignore" axis with a simple "on" and "off" settings, or 
with "off", "quiet" and "verbose" if I like to.

I can create the "Color" axis, no blood, sweat and tears, the original 
developer wouldn't even know it could be conceived.

If I somehow could hand out one Logger per instance, I can also create the 
equivalents of NDC/MDC in Log4J, per user, per application or whatever I 
want, without(!) changing the application code, or asking them to follow some 
particular pattern.


NOW, there are two important parts of the above;
 1. The Logger instance handed to the using code, has no encoding of how the 
output will be used (as now is the case). The API is dirt simple, everything 
else are "behind the scene implementation details" and "tools integration" 
problems/challenges.
 2. To make something like this work, tool support is extremely important. 
Otherwise setting it up becomes a nightmare.
 3. This can be done in other variations and the whole things is possibly not 
in the scope of SLF4J.
 (The world consists of 3 kinds of people; Those who can count, and those who 
can't.)

I just felt I wanted to throw something wild on the table, perhaps trigger 
some thought and revive last century thinking, which I consider current 
logging approaches to be ;o)

Personally I get somewhat excited with the above. Time to go for a cold 
shower, and return to reality. ;o)

Have fun looking at this.

Cheers
Niclas