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