ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siberski, Wolf" <Wolf.Siber...@tui.de>
Subject RE: [Vote] Logging
Date Tue, 08 May 2001 15:54:39 GMT
Peter Donald wrote:
> I would like to do Ant2 logging with logkit. Logkit is a lightweigh
logging
> toolkit developed a couple of years ago as an easy to use performance
> logging. It is part of the Avalon project.
> 
> I am willing to bet the first question asked is why we use this instead of
> either the Logging JSR or Log4j. The Logging JSR has recently been changed
> to JDK1.4+ only so that is not really an option. 
> 
> Log4j is a lto larger a product. It has significantly more features -
> object rendering, ability to build custom priorities, stack
introspectiong,
> internationalisation and a few more that I have probably missed. However
> along with this comes extra complexity, bulk and size.
> 
> Ant does not need any of these features; 
> * object rendering is not useful as tasks won't be directly interfacing
>   with that section (breaks IOC Container-component contract)
> * we don't need custom priorities
> * we don't need stack introspection because logging will already be
>   redirected on per task basis (again via IOC).
> 
> Log4j vs Logkit in size: 180 kb vs 20 kb
> 
> Logkit also has a minimal client interface; only variation on 
> three methods
> to learn for task writers - namely
> 
> debug( String message ); - log debug message
> debug( String message, Exception e ); - log debug message and an exception
> isDebugEnabled() - check if debug is enabled for logger - 
[snip]

Although I don't know if Log4J is the right choice for Ant,
I'd like to mention some points where I disagree with Your
evaluation of Log4J.

While Log4J is indeed not simple internally, it works completely
out-of-the-box. Although there are a lot of configuration options, 
no setup is necessary if You only use the basic features.

>From the task writers point of view the only difference to LogKit 
is that You have to access a statically declared Category to log.
Otherwise the interface is pretty much the same:

public class Sample {
  static Category cat = Category.getInstance("sample");

  public void foo() {
    cat.debug("Entered foo."); 
  }
}

If this is still considered too complex it would be possible 
to wrap Log4Js API without loosing any functionality (see below).

The size for the core (which supports logging to stdout
and files) is 66kb. Everything else is support for other 
log destinations (e-mail, Win NT event log, log server).
But the real question is if we should worry about jar
file sizes at all. I think more important issues are
API stability, robustness, etc. so we don't get impacted 
by development moves of the logging package project.

Although strictly speaking we don't need the advanced Log4J 
features, I can imagine quite a few cases where the
supported log targets can be useful (e.g. sending a mail
containing the error messages if a build fails).
During debugging it also helps to see where exactly an
error message comes from; Log4J is able to log method
name, file and line number even if it is called through 
a wrapper API. But if we decide for Log4J I see no
reason to hide it from the tasks. The logging 'aspect'
would be provided by Log4J directly. 

As it already provides a clean API to redirect output 
and plug-ins for different destinations so we wouldn't 
need to care about that anymore.

If You do large builds and investigate a problem it would 
be possible to enable debug logging only for a specific
task or only for the project engine, or whatever
selection is useful.

My summary: the advantages aren't that big, but the
disadvantages are even smaller :-).

Wolf

Mime
View raw message