Shouldn't this be posted at the commons-dev list? Or, at least, ALSO at commons-dev list?
Have fun, Paulo Gaspar > -----Original Message----- > From: Ceki Gulcu [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 5:11 AM > To: [EMAIL PROTECTED] > Subject: Comments on the commons-logging API > > > > Hello all, > > Given that log4j is such a low-level library, most organizations are > suspicious to tie their code to log4j, especially considering the new > logging API in JDK 1.4. > > Before going forward, it is appropriate to mention that these two APIs > are very similar. The classical usage pattern for log4j is: > > --------------------------------------------------------------- > > import org.apache.log4j.Logger; > > public class MyClass { > final static Logger logger = Logger.getLogger("some.name"); > > public void foo1() { > logger.debug("Hello world."); > } > > public void foo2() { > logger.info("Another message."); > logger.error("Stop that!", new Exception("The earth is getting > warmer.")); > } > } > --------------------------------------------------------------- > > As you are well aware by now, one of the important benefits of log4j > is that it can be configured at run time using configuration scripts. > You can have hundreds or thousands of log statement but only one or > two lines of code to configure log4j. > > The usage pattern for the JDK 1.4 logging API is: > > --------------------------------------------------------------- > import java.util.logging.Logger; > > public class MyClass { > final static Logger logger = Logger.getLogger("test"); > > public void foo1() { > logger.debug("Hello world."); > } > > public void foo2() { > logger.info("Another message."); > logger.error("Stop that!", new Exception("The earth is getting > warmer.")); > } > } > --------------------------------------------------------------- > > Do you notice anything similar? The JDK 1.4 logging API also admits > configuration scripts. Being part of the JDK, the common guess that > this API will supplant log4j some time in the future. > > It is not so easy to write a complete logging API. Users > come to realize they need the features present in log4j but absent in > JDK 1.4 logging API. Moreover, log4j runs with JDK 1.1 or later whereas > the JDK 1.4 logging API, requires, well, JDK 1.4. Most users can't > afford to tie their code to JDK 1.4. > > But they need logging and they need it now. A common strategy for > protecting against future changes and at the same time to benefit from > existing log4j features is to *wrap* log4j with a custom logging > API. Log4j actually has support to facilitate such wrappers. > > It turns out that such wrappers are not that trivial to write. I > frequently > receive email where a user runs into a problem with their wrapper and > requests help. More often than not, these wrappers are of poor quality > such that the cost of inactive (or disabled) logging statements is > multiplied by a factor of 1'000. > > Of course, not all wrappers are of poor quality. For example, the > commons-logging API is rather well implemented. Obviously, there is > still a cost for the wrapping but it won't be of a huge factor. > > The commons-logging API will try to use the JDK 1.4 API if present, or > the log4j API. The *current* preference is log4j I believe. Neat! > > Now, it just happens that the part where most users have difficulty is the > initialization of the log4j API. Where should the log4j.jar go? Where > do I put the log4j.properties files? Can I have different > web-applications have different log4j configurations? How do I > initialize log4j in an application server? Although there is ample > literature on the subject, much confusion remains. > > The commons-logging API as it wraps multiple logging APIs such > as Avalon's LogKit, log4j, JDK 1.4 has its own "discovery process". > Things were confusing before, they will be even more when > commons-logging API enters "common" usage. With some effort, it might > start making sense to you. However, your users will not show the same > perseverance nor enthusiasm. > > There will be also unexpected interactions between log4j and the > commons-logging API. For example, log4j 1.2alpha1 through alpha4 had a > very subtle bug which caused client code compiled with log4j version > 1.1.3 to throw exceptions when ran with log4j 1.2alpha. Inversely, > code compiled with 1.2alpha would crash when ran using log4j 1.1.3. > This problem was fixed in log4j beta. > > It is now sufficient for client code to be compiled with 1.1.x and to > run with 1.2 beta without problems and vice versa. Of course if > commons-logging compiled with log4j 1.2alpha the problem would be > sticky. It would not go away by compiling client code but only by > replacing > the commons-logging API. > > In the recent weeks I have also started to receive disturbing bug reports > where components using commons-logging API behave strangely. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7484 > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6764 > > I suspect that these problems will only worsen in the future. The > commons-logging developers will suspect a log4j bug and we will > suspect a commons-logging API bug. By increasing the number of > components required for logging you have doubled the probability of > bugs while the difficulty of resolving them has increased by a higher > multiple. > > Remember that the initial goal of introducing a wrapper API was to > protect our coding investment. If for whatever reason you decide to > drop log4j in favor of JDK 1.4 (or the other way around) a simple > string search-and-replace operation will do. Most IDEs support > search-and-replace operations on multiple files. All you have to do is > to replace "import org.apache.log4j.Logger" with "import > java.util.logging.Logger". > > I believe the saying is "a penny today is worth a promise of a nickel > tomorrow." By adopting a wrapper API, you are trading "a nickel of > today for a promise of a penny tomorrow." > > As long as you are aware that the supposedly free-lunch may turn out > to be an expensive and not so tasty meal after all... > > > -- > Ceki > My link of the month: http://java.sun.com/aboutJava/standardization/ > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
