ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <co...@brightspark.com>
Subject RE: [Vote] Logging
Date Tue, 08 May 2001 20:48:35 GMT
> -----Original Message-----
> From: Siberski, Wolf [mailto:Wolf.Siberski@tui.de]
> Sent: May 8, 2001 11:55 AM
> To: 'ant-dev@jakarta.apache.org'
> Subject: RE: [Vote] Logging 
> 
> 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 :-).

To be fair, the core .jar file from log4j 1.1beta6 is 90k. But I have to
agree, 90k is not that big, and aside from the size difference I think there
are some significant advantages to log4j. Aside from the power and speed, a
lot of people already use it, know it, and trust it.

Since Avalon was mentioned I have to say that actually the logger used in
Ant probably will not matter that much to me in the end as long as it is
relatively powerful, but w/regards to Avalon I must say that I like almost
everything about Avalon other than the fact that it uses Logkit. I have used
log4j extensively, want to start using Avalon as the framework for various
projects, and do not relish the though of having to integrate two logging
toolkits.

Mime
View raw message