Nicely stated. Though perhaps I don't care quite as much about the INFO stuff. (I keep my libraries on WARN by default).
We have to be humble. Velocity is often just a little library in a much bigger application. It always annoys me when I fire it up just to send an email and there are tons of messages. (admittedly, most open source libraries are worse). WILL On 9/24/07, Malcolm Edgar <[EMAIL PROTECTED]> wrote: > > +1 > > I agree completely with these guidelines. If a framework (Velocity) is > doing > its job correctly, it doesn't need to tell the world about it (INFO). > > regards Malcolm Edgar > > On 9/25/07, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > hey folks, > > > > for various reasons, i've been running Velocity from the command line > > a lot more lately, and i'm starting to find myself annoyed by INFO log > > messages (yes, even after all my log message/level/facility tweaking > > of the last few years). so i've started thinking that it'd be handy > > to have an established guideline for when the various log levels are > > appropriate/useful in developing a component library such as Velocity. > > does anyone know of somewhere where people have already thought this > > through and documented their conclusions? alternately, we should > > create our own on the wiki. here's my current thoughts (which still > > feel quite malleable): > > > > TRACE: This is the level for things that may be useful to know when > > debugging *Velocity itself*. These are unlikely to be useful to > > anyone else. > > > > DEBUG: This level seems most appropriate for information that would > > be used during development (aka debugging) of an application *using > > Velocity*. This would include all configuration settings (whether > > defaults or not) on runtime initialization, engine state changes such > > as the addition of a new Velocimacro, unhandled invalid references, > > resource loader activity, etc. This is not a level for things that > > would just be noise to a Velocity user. > > > > INFO: I increasingly think this is the least useful level for a > > component library like Velocity. I think it is best limited to > > things of interest to a Velocity user/app during production, which is > > not really a component type of thing to do. If we really wanted > > Velocity to make any production runtime info available, it probably > > would be through something like JMX, not through the logging API. > > Everything i see logging at INFO level right now should probably drop > > to DEBUG. > > > > WARN: Again, not very useful for us. I see this as legitimate for > > when the Velocity user is doing something that is likely unwise but > > not a clear error. Scanning our codebase, i see only one place in > > ResourceManagerImpl:510 where WARN seems appropriate. Too often we > > use it when Velocity recovers from an minor error, when the user tries > > to do something forbidden by the configuration, or when there has been > > a misconfiguration, all of which should be errors. > > > > ERROR: This is for when something goes wrong (whether Velocity > > recovers from it or not), when the user tries to do something not > > allowed by the configuration, and when there is a mis-configuration. > > Since we're talking about errors, some of the ones we catch and > > recover problem should probably be changed to throw exceptions. > > Velocity is meant to be a component library. It shouldn't be our job > > to clean up others messes; it's just our job to point out what went > > wrong and where as clearly as we can. > > > > FATAL: Once again, probably not really meant for a component like > > Velocity. Anything fatal to Velocity itself should just be logged as > > an error and passed up to the app or framework using Velocity. They > > can decide whether it's fatal to the app or not. > > > > Refinements, thoughts, or objections before i start acting on some of > > this? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
