ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Stevens <>
Subject Re: [Vote] Logging
Date Wed, 09 May 2001 06:12:28 GMT
on 5/8/01 8:04 PM, "Peter Donald" <> wrote:

> turbine has more lines of code than logkits core, is a custom system, has
> not had anywhere near the same level of testing as either log4j or logkit.
> You just reinvent a new logging toolkit inside turbine - sounds smart.

Peter, now you are making shit up. Go look at the code.

> yer - 1 time in close to two years it changed in a backward incompatible
> and I patched velocity for you. If you notice

Huh? That isn't true at all. We have had to fix the LogKit related code at
least two times now.

"adding a log manager to velocity to deal with logs the new
  avalon way :-) Using the example of the SAR deployer in avalon."


> grow up. Log4j has always been a moving target until recently with it's 1.x
> release. LogKit has only once broken backwards compatibility - both have
> been around for around 1.5-2 years? So you do the figures -- ooh guess
> which one comes in as more stable?


> so - people want to add if/while to ant, people want to incroporate return
> values from targets, people want to do all sorts of things. Luckily
>>> People build toolkits to be reused - could you imagine everytime you wanted
>>> use JDOM you had to create a wrapper around it - and make it generic enough
>>> that it fit other similar toolkits. Stupid - yes I would have to agree.
>> Huh?
>> What the heck do you think JAXP (or the proposed Logging API) is for?
> It has nothing to do with JDOM ;)

And JDOM has nothing to do with Log4J or LogKit. So, why did you bring it
up? Grow up.

>> People like the ability to swap out their XML parser
> because some ofthem have different implementation strategies - something
> which is not the case with logging.

Huh? Log4J and Logkit have two different implementation strategies.

>> (and logging implementation) at will without needing to re-write their
> application.
> yer - right. Yet to see that. People like to swap things in and out when
> there is different implementation strategies or a generic way of specifying
> features. Logging toolkits are unlikely to have either - they merrily have
> pluggable backends (appenders/logtargets/formatters/whatever).

Nope. You are wrong.

> Question - why doesn't the JDK have pluggable HashMaps - your positions
> would indicate that they should - and that they should have wrapper
> interfaces to interact with them.

Stupid question. I can't answer JDK questions because I didn't write the JDK
and I also don't agree with quite a lot of stuff in the JDK. Classloaders
are a great example of a crappy design. HttpUrlConnection is even worse.

> Same goes for ClassLoaders - why doesn't the JDK allow pluggable
> classloaders - your logic dictates that they should cause some could want
> them.

See above.

> So again - what advantage do you see in duplicating the work in ant that
> exists in other projects?

So, then why do we have two logging systems? Lets get rid of LogKit and
focus on Log4J.


If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous

View raw message