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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
