If logger implements org.slf4j.Logger, then one can write
String name = "Scott";
logger.debug("Hello Scott");
logger.debug("Hello {}", name);
Both log statements will print as "Hello Scott". However, the latter
log statement will contain 'name' as a parameter. The SLF4J
implementation can choose to preserve or to discard this parameter in
the LoggingEvent.
SLF4J allows for 0,1,2 or an array of parameters. Thus, you can write
Map aMap = ...;
List aList = ...;
logger.debug("Hello", new Object[]{new Integer(37), aMap, aList});
First off, I've come back from some leave, and prior to that was
extremely overloaded at work, so my attention to detail on this thread
is limited.
Am I correct in distilling that the crux of the _driver_ to do this is
to support the above, and only that feature? This is 'nice' but really
not that high a priority I would have thought.. Given the vast
majority of people are on Java5+ platforms, a source and binary
compatible way is to introduce a simple 'log4j-java5plus' extension
jar that has something like this:
public class LogUtils {
..
public static void debug(Logger log, String message, Object...
args) {
if (!log.isDebugEnabled()) {
return;
}
log.debug(getFormattedMessage(message, args));
}
..
private static String getFormattedMessage(String message,
Object... args) {
String formattedMessage = message;
if (args != null && args.length > 0) {
formattedMessage = String.format(message, args);
}
return formattedMessage;
}
..
Then the code is changed to:
LogUtils.debug(LOG, "Hello %s, your age is %d", name, age);
Now, that bypasses slf4j completely, and maintains source & binary
compatibly, and can easily be migrated to. My point is not to suggest
log4j introduce the above, or to dissuade from considering slf4j
integration more generally, but if the above feature is it... it
really doesn't seem like a massive driver that breaks binary
compatibility and possibly alienate a whole bunch of people (which it
could, and that could badly tarnish the log4j 'brand' as it were).
So I'm not in favour of rushing any decision at all.
Paul
