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. 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. 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. >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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
