At 15:18 27.03.2002 -0600, Morgan Delagrange wrote: >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.
So, if I understand correctly the reason for adopting commons-logging API is for convenience rather than non-intrusiveness as a library (with respect to logging). With commons-logging, the end user will only have to configure the logging API that common-logging selects (or detects) but the selection mechanism is dynamic such that there are many ways and reasons for which the selected API will be the wrong one. This is the uncertainty factor I am talking about. Uncertainty breeds confusion and confusion breeds despair. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
