6 Jun
2008
6 Jun
'08
2:19 p.m.
On Jun 6, 2008, at 1:57 PM, Jonas von Malottki wrote:
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?
Well I don't see anything wrong with a simple indirection level that
only forwards to the underlying implementation. That said if sl4j
(which I haven't used) is really open and doesn't bring any potential
issue we could use it too directly as our logging interface. To be
honest what sl4j does was what commons logging was supposed to do and
we all know how it ended up so seen the extra effort we have to create
an adapter for any logging subsystem I don't know if it's worth it.
Let's see what others think.
Thanks
-Vincent
<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.
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