On Thu, 28 Mar 2002, Jeff Schnitzer wrote: > > From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] > > > > Yes, the defining advantage to the commons-logging API that I see is > that > > it > > allows users to adopt a single logging implementation, which confers > real > > What needs to be appended to that statement is "...if everyone codes to > the commons-logging API". The exact same statement can be reconstructed > using "Log4J API" and it is equally true.
Not true. If part of the code is using commons-logging, and part is using LogKit - you still have a single logger to configure ( LogKit ). All the code written with commons-logging API will 'adapt' to whatever logging implementation you use. If you code with log4j APIs and use the code with components using LogKit - you have 2 loggers to configure. > If everyone uses commons-logging, then only one logger must be > configured. If everyone uses Log4J, then only one logger must be > configured. If third-party software is using different loggers, then > you have to configure multiple loggers no matter what API your code > uses. Commons-logging doesn't impose any logging implementation - if the third-party software is using log4j, logkit, jdk1.4 - or a logger that can implement commons-logging APIs - you have to configure a single logger. Using log4j ( or a specific logger ) is the action creating the dependency between your code and the logger implementation. It's exactly like SAX and Xerces - if you code with SAX/DOM - your code will work with any parser. If some code is using Xerces or Crimson APIs - it'll require that specific parser. > It seems to me that the commons-logging API just adds Yet Another > Logging API... especially when someone gets the bright idea to make a > "native" implementation of the API for performance reasons. There is already a 'native' implementation - if no other logger is found it'll just do println(). > At least with Turbine, Struts, (Maverick :-), etc, there are some > fundamentally different approaches to the problem of how to publish a > web application. Logging doesn't seem that complicated. The massive > duplication of this basic feature in the Jakarta codebase is silly, and > trying to build an abstraction layer on top of it seems even sillier. The duplication of the basic feature may be silly, but building an abstraction layer is IMHO the only possible solution. I see no problem with having multiple logger implementations - having a different API on each one is the problem. What else do you propose ? There are at least 3 different loggers, little chance to see 2 go away - and people using all of them. Commons-logging allows to write code that will not be 'tied' to any particular logger implementation - and that's a very good thing. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
