Stefan Bodewig wrote: > On Sat, 16 Aug 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > >> Regarding ant logging system - I think we should eventually reopen >> the subject and pick a logger API > > I fail to see the benefit of using a different logging system, but I'm > ceratinly open to discuss it. > > Ant's system currently is an event based system which goes beyond > simple logging and we'd still have to maintain that anyway. It is > getting used for much more things than just logging. AntClassLoader > uses buildFinished events to deregister and clean itself up to allow > garbage collection for example.
I know. The problem is that we also use this logging system for debug info - and IMO at least this doesn't work as well. If you want to find what's wrong with a build ( and wrong things happen with complex build files ) - you can enable debug/verbose, but that's far too much info to process. Something like log4j would allow us to enable debug on a particular target or task. The second issue with using the current event-based system for debug is the performance - we need to _allways_ do the string concatenations, and that may have a significant impact on performance. >> then start using the normal if( log.isDebugEnabled()) log() that >> prevents useless string concatenations and calls. > > Vadim's stats say that cloning of the build listener list and > iterating through them are the problem, not string concatenation. That's one problem. IMO string concat is also a problem, but it won't show in OptimizeIt if you do time-based profiles. > And I doubt that you could implement isDebugEnabled() at all using > Ant's BuildListener concept as the listener decides what to log, Ant > just passes the events along. It is very well possible that one > listener will log a MSG_DEBUG message while another one will not - and > both are there at the same time. That's exactly the problem. Most of the time the debug messages are not logged by anyone - and if you need them, usually you need a small set. By default that's hard to get, and in the most common use case ( no debug ) it is inefficient. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
