on 5/8/01 8:04 PM, "Peter Donald" <[EMAIL PROTECTED]> 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." <http://jakarta.apache.org/cvsweb/index.cgi/jakarta-velocity/src/java/org/ap ache/velocity/runtime/log/LogManager.java?rev=1.1&content-type=text/vnd.view cvs-markup> > 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? Log4J. > 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. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
