----- Original Message ----- From: "Ceki G�lc�" <[EMAIL PROTECTED]> To: "Jakarta General List" <[EMAIL PROTECTED]> Sent: Wednesday, March 27, 2002 2:43 PM Subject: RE: Comments on the commons-logging API
> At 11:49 27.03.2002 -0600, Rodney Waldhoff wrote: > > >But this isn't really the reason commons-logging was created. Note that > >most of the commons components are just that--tiny libraries meant to be > >integrated/incorporated into larger frameworks and larger applications. > >Some of these components need/want logging capabilities, or at least some > >people need/want some components to have logging capabilities. But it seems > >a obtrusive for some tiny library to dictate the logging framework (if any) > >that should be used by the larger application that contains it. So the > >component is stuck with a decision between not using logging at all, or > >forcing some "standard" logging implementation upon the larger framework, > >and the containing application is stuck with either converting everything to > >this "standard" logging implementation (and hoping that each component > >agrees on what that is) or having a heterogeneous set of logs and logging > >implementations. Search-and-replace code switching isn't really an option > >for the commons components, or at least not a terribly good one. > > If your library chooses to use logging API XYZ, this does not impose > XYZ to the clients of your library. Your clients can use the logging > library they prefer (if they are using logging API) and your library > can use XYZ. One choice does not necessarily influence the other. For > example, the fact that JBoss uses log4j does not impose a logging > library to the bean developer. Similarly, Tomcat's logging library > does not prevent web-app developers from using log4j. But it doesn't facilitate it either. Here's the problem, as I see it. Suppose Commons component A decides to adopt Log4J, Commons component B decides to adopt LogKit, and Commons component C adopts JDK1.4 logging. They will all minimally function with the right jars in the classpath. However you (the end-user) are left with maintaining configuration for 3 different logging APIs, which is tedious at best. When you take into account cool features like variable log levels, Log4J appenders and the like, you're pretty much guaranteed to swallow up useful configuration options because sophisticated configurations are too difficult to maintain over mutiple logging implementations. Contrarily, if all three Commons components use a logging facade, you can focus all your configuration efforts on one logging implementation. Sure, there is a trade-off; you don't have access to all the features, and the interface between the facade and the implementation must be maintained. But the benefits are not just political; they potentially make the end-users configuration much easier. Even if all Commons components used the same logging implementation (Log4J for example), other projects in Jakarta-land may choose otherwise. If you add enough Jakarta projects to your environment, you eventually end up with the scenario described above. It's a worthwhile effort to attempt a logging solution that plays well with the Jakarta community at large. I think in many cases the Commons Logging component can fill that role. To take your analogy of trading a nickel's worth of functionality for a penny payoff later (only because I'm dying to play off of it, FEEL FREE TO IGNORE THIS PARAGRAPH :), yes each logger implementation delivers that nickel. However Log4J is delivering a US nickel, LogKit a Canadian nickel, and JDK 1.4 a wooden nickel. Each end-user becomes a bank that must constantly monitor the exchange rate between those nickels, including those wooden nickels which aren't worth a damn. Some banks would prefer the guarantee of a good penny than deal with the hassle of all those nickels. :) > In other words, the argument about (jakarta-commons) components > dictating a logging API to the containing application is widely > accepted although very dubious in my opinion. > I don't know if the word "dictate" quite captures it. > > Anyway, I think we have been through all this already. I do not expect > to be able to convince anyone altough I suspect uncertainty and the > bug reports will, slowly but surely. It may be difficult to maintain. The most we can do to mitigate it is frequent releases and careful version management. > >Commons-Logging is meant to provide an alternative solution: create a > >facade/adapter around an arbitrary logging API, use it at the common > >component level, and allow the user (the containing application) to select > >which specific logging implementation (if any) to use. Then the same binary > >works everywhere, and in many (most?) cases, the commons-logging will just > >quietly do what you hope it would. (If you've got log4j, it uses it. If > >you've got JDK 1.4, it uses that. If all else fails, it doesn't do > >anything.) > > I don't think "hoping quitely" and computers get along very well. > > >An arbitrary application or system shouldn't feel compelled nor even > >(necessarily) encouraged to use commons-logging. That's not what it's there > >for. It's there to allow the library components to delegate that decision > >to the containing application. > > I understand your argument. I have already exposed mine. Thanks for your > attention. Ceki > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
