I'd argue that this is a misuse of a logger. A logger isn't an IO stream and
shouldn't be treated like one.
Here's how I've implement this kind of thing:
public static void writeMap(Map map, Writer writer)
{
for(Iterator keys = map.keySet().iterator(); keys.hasNext();)
{
String key = (String) keys.next();
String value = (String) map.get(key);
writer.print(key);
writer.print('=');
writer.print(value);
writer.println();
}
}
...
if(logger.is{X}Enabled()) {
StringWriter writer = new StringWriter();
writeMap(map, writer);
logger.{X}(writer.toString());
}
Now, If you want to argue that abstracting out those 4 lines of code for
values of X is useful, I'd argue that the marginal utility is low. The
number of cases where you want to dump a Map to a log at levels other than
debug is tiny.
IOW, at Error, you want a message like "IP address not found for Domain Name
= {}", not a list of all known domain/IP mappings. Similarly for Info "IP
address {} found for Domain Name = {}". Warn is something like "IP address
null for Domain Name = {}". Of course, these are all at the semantic level
above Map.
Map's internal logging should be much sparser. Earth shattering events like
"HashBucket claims 5 elements, but only found 4: Panic!" IE, the whole thing
is FUBAR'd. At least until you get down to Trace level stuff.
Just my $0.02
> -----Original Message-----
> From: Steven Caswell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 06, 2002 4:13 PM
> To: 'Jakarta Commons Developers List'
> Subject: [LOGGING] Request for API change (was RE: [VOTE] Logging 1.0
> Release (again))
>
>
> 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
> [EMAIL PROTECTED]
> 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:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
