Re: wm.log time stamp broken?

Endre St=F8lsvik wrote:

>On Tue, 4 Apr 2006, Keats Kirsch wrote:
>
>| I have also been reading up on SLF4J, and I think I'm convinced that i=
t is a
>| better approach.  For me it's mainly because of the log interface, whi=
ch seems
>| more elegant and efficient..  They use formatted log messages which av=
oid
>| having to guard your logging statements with level tests or build up s=
trings
>| that are never used.  I also like that the Log4J founder is behind it.
>
>I don't think it's any more efficient as such. And for several=20
>log-systems, they will still have to wrap the actual loggers (unless the=
=20
>logging-system natively implement the interfaces, as log4j probably will=
=20
>do at some point).
>
>The new "formatting methods" aren't all that fantastic in my opinion - a=
s=20
>I understand it, you can't shove primitives (numbers, booleans) in there=
 -=20
>and then you're back at unnecessary object-creation, or=20
>string-convertions, or the "wrapping if".
> =20
>
Well the boxing issue will always be there.  Some say it's an inherent=20
flaw in the design of Java vs a purely object oriented language like=20
Smalltalk.  Personally I think it was a reasonable compromise, but=20
that's a religious war I don't care to fight.

>  The if (log.isDebugEnabled()) log.debug("lala"); semantics have never=20
>bothered me at all - i have macros/templates for all these anyway - and=20
>then I'm _sure_ that I won't create unnecessary objects or do conversion=
s=20
>or concatenations.
> =20
>
I don't like having to type/look at the extra code.  Sometimes you may=20
still need it, but you should be able to skip it at least 90% of the time=
.

>  At any rate, I believe that these new methods will be incorporated in=20
>log4j too, soon, as they are a novel solution to the "wrapping ifs" - bu=
t=20
>not in all circumstance: log.trace("there are "+i+" items in the list");=
=20
> =20
>
That would be:

log.debug("there are {} items in the list", new Integer(i));=20

or with auto-boxing:

log.debug("there are {} items in the list", i);

Yes, without the guarding "if" you would have to create an Object=20
whether you have trace enabled or not. That's a simple optimization to=20
make when it's warranted.=20

>But yes, definately something to consider! At any rate, one should do a=20
>overhaul of the entire logging strategy, cleaning up every log statement=
,=20
>re-evaluate the level at which the log-statement outputs (there are way =
to=20
>much at info level now - "trace" should be employed for most output), an=
d=20
>use the decided-upon native loggers instead of implementing some=20
>inefficient wrapping or "containing" idea.
> =20
>
Actually, SLF4J doesn't support the trace() method.  From their FAQ:

2.6 Why doesn't the |org.slf4j.Logger| interface have methods for the=20
TRACE level?

The addition of the TRACE level has been frequently and hotly debated=20
request. By studying various projects, it looks like the TRACE level is=20
mostly used to disable logging output from certain classes without=20
needing to configure logging for those classes. Indeed, the TRACE level=20
is by default disabled in log4j and other logging systems. We believe=20
that the same result could be achieved by adding the appropriate=20
directives in configuration files.

Thus, in the majority of cases the TRACE level has the same semantic=20
meaning as DEBUG. In such case, the TRACE level merely saves a few=20
configuration directives. In the rare but interesting cases where TRACE=20
has a different meaning than DEBUG, Marker=20
<http://www.slf4j.org/api/org/slf4j/Marker.html> objects can be put to=20
use to convey the desired new meaning.






-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
that extends applications into web and mobile media. Attend the live webc=
ast
and join the prime developer group breaking into this new coding territor=
y!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642