----- Original Message ----- From: "Paulo Gaspar" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 7:16 AM Subject: RE: Problems with commons-logging
> Morgan, > > > It looks like your reading of my posts is as incomplete as Tim's. > I am going to quote myself a bit from a posting in this thread > some days ago: I was agreeing with Tim's assertions, not disagreeing with posts you made last week. > > (3) There is a class-loader based implementation for the logger > factory (2) that tries to find out which API is available. This > is not good for some applications but is quite practical for > others and IMHO should be available. > - You can configure via API what are your most favorite and > less favorite logging APIs and the discovery process will > follow that order; This sounds like a good feature. Note that it is configuration for the logging abstration, with which I have no issue. I don't agree with configuring the underlying logging engine. > - You can set a "minimum common denominator" configuration > that works for any of the APIs available (e.g.: all the big > 3 accept logging to a file with rotating file names). > > See? The essential of the idea is to be able to configure which is > the most favorite and less favorite logger and tell it to log to a > file with a given name. > The former sounds fine, but I don't think that a default log file is a good idea. To use Log4J as an example, what happens if there is a log4j.properties in the classpath. Which is ignored, the log4j.properties configuration? Why? Why not? Or do you add an additional appender specifically for the logger abstraction? What if it happens to point to the same file as one of the Log4J appenders? I think we're better off just avoiding these issues, at least initially. > Velocity (the "component" I know better) is much easier to use > because it does something like this. > > Even the guys that do not really know what logging is and how it > works, get the advantage of Velocity logging with minimal trouble. > Most of them do not even now how it got there but still use it to > understand to debug their templates. Providing default logging configurations makes more sense for an integrated system like Velocity than it does for component development. It's quite likely that the environment that uses these components already has its own logging configuration. > > Have fun, > Paulo Gaspar > > > > > -----Original Message----- > > From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 06, 2002 6:21 AM > > To: Jakarta Commons Developers List > > Subject: Re: Problems with commons-logging > > > > > > I agree with Tim's basic sentiment. We could design a generic > > configuration > > engine, tweak it to death, and it could still be unsatisfactory > > wrt. tapping > > the essential features of all the logging variants. And, in any case, a > > generic logging interface does not need to be included in the > > first release; > > we can always add it later if there actually is a need. It would not even > > need to constitute a revolution, since it should be possible to place a > > configuration layer on top of the logging facade without changing existing > > interfaces. > > > > Speaking as a user of logging APIs, a generic configuration > > interface would > > be a non-feature to me. The first thing I would do is explore the API of > > the underlying logger implementation, since it would always have more > > features than the abstraction. Log4J for instance provides lots of > > flexibility with the configuration of its appenders (including custom > > appenders); that would be difficult to capture in an interface > > that also can > > configure LogKit without lots of unsupported options. > > > > We need a logging abstraction, because we have to be able to program > > components in a log-agnostic fashion. Abstracting the _configuration_ of > > logging is not strictly necessary however, since it does not > > change the way > > components are developed at all. > > > > - Morgan > > > > ----- Original Message ----- > > From: "Tim Vernum" <[EMAIL PROTECTED]> > > To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> > > Sent: Tuesday, February 05, 2002 10:38 PM > > Subject: RE: Problems with commons-logging > > > > > > > > > > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] > > > > > > > > Configuration is not done by a components, therefore it is > > > > > outside the scope of the common-logging package. > > > > > > > > I still do not get WHY you really need to impose such > > > > limitations. > > > > > > 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. > > > > > > 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". > > > > > > 3) The more you add, the more people have to download. > > > The idea is to keep the component small. > > > > > > 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. > > > > > > 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. > > > > > > This component has a purpose. > > > It fulfills that purpose without needing a configuration > > > mechanism. > > > Don't go adding one. > > > > > > At some point you need to draw a line in the sand and say > > > "This is the scope of the project" > > > > > > > > > NOTICE > > > This e-mail and any attachments are confidential and may > > contain copyright > > material of Macquarie Bank or third parties. If you are not the intended > > recipient of this email you should not read, print, re-transmit, store or > > act in reliance on this e-mail or any attachments, and should destroy all > > copies of them. Macquarie Bank does not guarantee the integrity of any > > emails or any attached files. The views or opinions expressed are the > > author's own and may not reflect the views or opinions of Macquarie Bank. > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > _________________________________________________________ > > 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]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _________________________________________________________ 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]>
