ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [Vote] Logging
Date Tue, 08 May 2001 20:57:44 GMT
At 05:54  8/5/01 +0200, Siberski, Wolf wrote:
>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.

right - so does make though ? ;)

>>>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:

actually no - they are even the same in that aspect aswell ;)

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

what most people do.

>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. 

JDD was farily concerned about it - me I don't care but others seem to ... ;)

>I think more important issues are
>API stability, robustness, etc. so we don't get impacted 
>by development moves of the logging package project.

right - compare stability of logkit vs log4j over their full times (or even
just of lifetimes at Apache). LogKit has changed incompatibly once (just
recently in preparation for release) since it's initial creation while
log4j could not say the same (though to be fair I haven't heard of any
compatibility issues between the 1.x versions of log4j).

>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. 

you hide it from tasks because it is not functionality that they will use,
need or desire. Could you imagine if stack introspection was part of
servlet API? 

>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.

and thats different from logkit how ? ;)

>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.

and thats different from logkit how ? ;)
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message