Hi Jonas,
Side note: It's great to see someone diving into the code. We need
more of you so please continue to make proposal, and do forrays in the
code :)
see below
On Jun 6, 2008, at 11:25 AM, Jonas von Malottki wrote:
> 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 */
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.
Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs