Answer inline: > -----Original Message----- > From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 06, 2002 7:36 PM > > ----- Original Message ----- > From: "Paulo Gaspar" <[EMAIL PROTECTED]> > Sent: Wednesday, February 06, 2002 7:16 AM > > > 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.
Sorry, maybe I was a bit rough on this. However, I was talking about the bits I quote that talk about "configuring a file for logging" and not about "using some configuration file". > > (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. Yes, this is the consensual bit. > > - 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. These issues you raise are much more interesting but I think of them as something to be considered instead of a reason against. First, nothing of what I HAS to be used. The developer has the final decision on the policy to apply. Using the Velocity example again, the user of the component using the log wrapper, might get a default configuration unless he changes it. The default could be logging to a file and ignoring any configuration and it could be changed to use a sub-logger from an existing configuration. > > 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. The Velocity template engine is not an integrated system. It is a component (although not a very small one). Some of the tools in the Velocity project can be understood as integrated systems, but the stuff I am talking about is related to the template engine. Have fun, Paulo Gaspar -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
