On Wed, 6 Feb 2002, Tim Vernum wrote: > 1) The more you add the more you have to support. > If someone adds code to commons-logging to do basic > configuration, then commons has to support it. > You have to make sure it's not creating security problems. > You have to support it for any future logging kits that > commons-logging supports.
The why add commons-logging at all :-) ? If we don't add it we don't have to support anything. By this aproach, it may be easier to create a Category impl. that logs to logkit and one that logs to 1.4 log, and we don't have to maintain anything at all. A get/setAttribute that will allow passing of impl. specific info without hardcoding the class names is not that hard to maintain. > 2) The more you add the more users expect. > It's a "slippery slope". > If you add a bit of configuration, then people want > "a bit more". See my previous point - the we shouldn't provide anything at all, and the people will know what to expect. > 3) The more you add, the more people have to download. > The idea is to keep the component small. :-) That's a very good argument - try to subscribe to tomcat-dev, xerces-dev and most jakarta lists ! > 4) We don't need YetAnotherLoggingAPI. > This is a minimal wrapper around a few logging toolkits. > If you keep adding more functionality, you end up replicating > log4j/logkit. We don't need that. Commons-logging _is_ yet another logging API - regardless of what we do or think. If you ask people to use you interface for logging and abstract different implementations, you are providing an API. I'm sorry log4j or logkit APIs didn't succeed in beeing adopted, jdk1.4 logging is out of question ( since it depends on 1.4 ). By all accounts, we are developing an API, and it's likely to have a very large user base ( anyone using commons will likely depend on it ). If we do that, let's at least make sure it doesn't suck ( and requiring the user to hardcode calls to impl. for things that could be easily abstracted makes it a very bad API ). > 5) If you add it, you've got to do it properly. > What methods will you add? > setConfigurationFile( String filename ) > What about the SimpleLog, how do you configure that? > What about logging kits that don't use file based > configuration? > Once you walk that path, there's a heck of a lot > of work do to. setAttribute/getAttribute is used in a lot of APIs without problems - to provide access to implementation specific data - servlet, SAX are reasonably successfull, and nobody complained about those methods. Each impl will document what attributes it supports, and we can define few 'recomended' names ( like servlet API or SAX defines ). A logger is not required to support any attribute. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
