[Tikal-development] FW: Which logging framework to use ?

[Yanai F. <ya...@gm...>]

 

 

  _____  

From: Lior Kanfi [mailto:li...@ti...] 
Sent: Wednesday, January 25, 2006 5:23 PM
To: Yanai Franchi
Subject: Re: Which logging framework to use ?

 

to mailing list.

On Wed, 2006-01-25 at 10:41 +0200, Yanai Franchi wrote:



Hi,

Following my conversation with Rafi, I did a small research regarding a
logging framework. Specifically, I checked the following loging frameworks:

1.      Log4J

2.      Apache-commons logging

3.      JDK logging

4.      SLF4J.

 

I'll start with the bottom line. Assuming we do NOT need an abstraction
bridging between different logging implementations, my recommendation is to
use Log4J. 

 

 


Why not  commons-logging and what is the alternative to commons-logging?

If you want to know about the actual problems commons-logging causes and why
using class loader hacks to implement a dynamic discovery process is
generally a bad idea, read the article Taxonomy of class loader
<http://www.qos.ch/logging/classloader.jsp>  problems encountered when using
Jakarta Commons Logging.

Commons loggiing solves a theoretical problem (I am using the word
'theoretical' here, since almost everyone that uses it, uses Log4J as the
logging implementation anyway), it is just unfortunate that it became so
popular so fast.

However, there are alternatives. If you really need to use a Logging facade
(which I do not think you do), you should try out Simple Logging Facade for
Java <http://www.slf4j.org/>  (SLF4J), which uses static (compile time)
binding of the Logging implementation, e.g. avoids the above stated
problems. They even have a gradual migration path
<http://www.slf4j.org/manual.html#gradual>  from Commons Logging. 

Why shouldn't we use Java Util Logging (JUL)?

While Log4j and JUL are almost conceptually identical, they do differ in
terms of functionality. Their difference can be summarized as, "Whatever JUL
can do, Log4j can also do - and more." They differ most in the areas of
useful appender/handler implementations, useful formatter/layout
implementations, and configuration flexibility. 

JUL contains four concrete handler implementations, while Log4j includes
over a dozen appender implementations. JUL's handlers are adequate for basic
logging - they allow you to write to a buffer, to a console, to a socket,
and to a file. Log4j's appenders, on the other hand, probably cover every
logging output destination that you could think of. They can write to an NT
event log or a Unix syslog, or even send e-mail. 

JUL contains two formatter classes: the XMLFormatter and SimpleFormatter.
Log4j includes the corresponding layouts: the XMLLayout and SimpleLayout.
Log4j also offers the TTCCLayout, which formats LoggingEvents into
content-rich strings, and the HTMLLayout, which formats LoggingEvents as an
HTML table. 

While the TTCCLayout and HTMLLayout are useful, Log4j really pulls ahead of
JUL in the formatter/handler arena because of the PatternLayout.
PatternLayout instances can be configured with an enormous amount of
flexibility via string conversion patterns, similar to the conversion
patterns used by the printf function in C. In PatternLayout conversion
patterns, special conversion characters are used to specify the information
included in layout's formatted output. For example, "%t" is used to specify
the name of the thread that started the logging of the message; "%C" is used
to specify the name of the class of the object that started the logging of
the message; and "%m" specifies the message. "%t: %m" would result in output
such as "main thread: This is my message." "%C - %t: %m" would result in
output such as " org.nrdc.My-Class - main thread: This is my message." The
Pattern-Layout is extremely useful, and JUL's two formatter classes don't
come anywhere near to matching its versatility. It's not uncommon for JUL
users to write their own custom formatter class, whereas most Log4j users
generally need to just learn how 

Log4j allows developers to associate layout instances with appender
instances, and configure layouts on a per-instance basis. This includes
PatternLayout instances - you can set the conversion pattern each uses in
the configuration file. During development, it usually isn't a problem to
recompile an application to adjust its logging configuration; after
deployment, however, you may want to be able to tweak or even completely
reconfigure your application's logging without recompiling. In that case,
Log4j offers more flexibility, especially pre-Tiger JDK.

Log4j provides a lot of functionality that JUL lacks, although JUL is
catching up. JUL could definitely be extended to do what Log4j does - you
could write more handlers, reimplement the PatternLayout for JUL, and
upgrade JUL's configuration mechanism, all without extreme difficulty. But
why do that when Log4j has had those features for years? 

GUI for Log4J

There are several GUI on top of Log4J we can use:

1.      Lumbermill - http://traxel.com/lumbermill/ - Lumbermill is a Swing
log processing and distribution system for Log4j and Sun JSR-47
(java.util.logging). The Lumbermill project is hosted on SourceForge
<http://sourceforge.net/projects/lumbermill/> .

2.      Chansaw - http://logging.apache.org/log4j/docs/chainsaw.html - It's
a GUI-based Log viewer.

 

Thank you,

Yanai

 

 

 


-- 
Lior Kanfi <li...@ti...>
Tikal