[xwiki-devs] Logging architecture proposal
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
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
Hi Vincent, Very fast response time, thats cool.
<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.
Very good. :)
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.
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
On Jun 6, 2008, at 1:57 PM, Jonas von Malottki wrote:
Hi Vincent,
Very fast response time, thats cool.
<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.
Very good. :)
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.
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
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
participants (2)
-
Jonas von Malottki -
Vincent Massol