Hello X-Wikians,
I am currently browsing the Xwiki Code and thus found the current
handling of the logging to catch my eye.
I filed a jira idea (XWIKI-2437) to use slf4j as logging abstraction. it
wasn't until this mornig though that I found the new logging
Architecture in the component sub part, and also Vincent pointed me 20
minutes later to it.
Still even with the logging pushed through the
org.xwiki.component.logging.Logger interface I have a suggestion.
A very good thing at the slf4j and particularly one of the
implementations is that building of the logging strings can be deferred
to the logger. I will explain that with an example:
Current Logger interface you will have to do this (or something similar)
LOG.debug("my debug message is " + var1 + " " + var2 + ": "
+ var3 );
This will force the Java VM to build the string and then call the
function to realize later that the string will not be logged. Now one
could introduce an if statement with log.isDebugEnabled() before any
such statement, but that is kind of tedious and clutters the code.
In slf4j you would write something like this:
LOG.debug("my debug message is {} {}: {}", var1, var2, var3);
Thus the function will be called but the string operation can take place
iff the string will really be logged. (see
http://www.slf4j.org/manual.html)
So my proposal is to give the logging interface a little bit of slf4j
flavor and introduce log statements with varargs or Object arrays like:
public void debug(String msg, Object... args);
/* plus all the other loglevels */
If one wants to use log4j then a simple wrapper could be written to
format those args before log it depending on the loglevel.
Thinking a bit further, slf4j does already that what it is intended with
the new component logger since the implementations are deploytime
pluggable (currently logback, simple logger, log4j and jcl can be used
as backend) and slf4j is just a facade to the logging system, thus
fulfilling the component based approach. Since reuse is better than
reinvent...
cheers
Jonas