6 Jun
2008
6 Jun
'08
1:57 p.m.
Hi Vincent,
Very fast response time, thats cool.
Very good. :)
JDK logging and commons logging are different implementations with their
own semantics. slf4j is just a facade for logging, without an
implementation by default. Thus it tries to standardize logging.
I do not take for granted that slf4j is the ultimate logging interface.
I am just a fan of "reuse before reinvent". Also I am a fan of
delegating the work of maintenance where it belongs to, which in this
case does the slf4j community (mostly Ceki Gülcü, the inventor of log4j).
The final question there is to answer is: Are there really enough
benefits in implementing one's own logging indirection layer that
outweight its potential risks like introducing new bugs, maintenance
work and taking away the focus from what is really necessary?
Don't get me wrong I am very much pragmatic. If there is a better
solution than slf4j I would switch (given that it is stable and works).
But for now my experience with slf4j has been very good.
Keep up the good work with xwiki.
nice greetings
Jonas
<snip>
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 */
Sounds good to me. I'm in favor. 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...
Well if that's the case then why create sl4j since there's already
commons logging and even JDK logging? :)
So you see you cannot take for granted that sl4j is the ultimate
logging interface and I prefer to have XWiki's own interface (even if
it does less things) so that we can adapt it to any implementation.