[LOGGING] Request for API change (was RE: [VOTE] Logging 1.0 Release (again))

[Steven Caswell <st...@yahoo.com>]

I want to revisit one of the issues noted below. A couple of weeks
before the VOTE was posted I made a request for a couple of these.  I
agree with not doing the third item (configuration) and can live without
the second (though arguments for the first are valid for this one as
well.  But I believe not having the first is a serious drawback.

> There are a number of suggested changes that are *not* 
> included, and I propose that we continue to not include them:
> * Adding a generic "Level" concept (either as a unique class or
>   as a set of integer constants) to the Log interface.
> * Adding a log(Level, String) method to the Log interface.
> * Adding mechanisms to configure loggers through the Log interface.
> 
> Going down the path of implementing any of these in the 
> commons logging wrapper would violate the principle on which 
> this API was designed, of being a very thin facade over the 
> facilities of multiple underlying wrapper implementations.
>
The lack of a Level concept in the API makes abstraction of logging code
more difficult than it should be.  For example, suppose I want to write
a method in a utility class that logs the contents of a Map.  This might
look something like the following:

public static void logMap(Map mapToLog, Log logger, ??? level)
{
    for(Iterator keys = map.keySet().iterator(); keys.hasNext();)
    {
        String key = (String) keys.next();
        String value = (String) map.get(key);
        if(level == TRACE) logger.trace(key + "=" + value);
        else if(level == DEBUG) logger.trace(key + "=" + value);
        else if(level == DEBUG) logger.debug(key + "=" + value);
        else if(level == INFO) logger.info(key + "=" + value);
        ...etc for each level
    }
}

The difficulty in this is how to identify the level. Without a level
concept in the API, the application is forced to invent its own, which
it shouldn't have to do. Or the application can defined multiple
versions of the method, one for each level. 

I disagree that going down the level path would violate the thin façade
principle.  In fact, the API has already introduced the level concept by
exposing different level methods (i.e., Log.isTraceenabled(),
Log.trace(), etc.). Adding a set of constants to consistently identify
levels would make the already-existing level concept more robust, And
would make significant isolation of logging code must more reasonable to
achieve.


Steven Caswell
stevencaswell@yahoo.com
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>