+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] > >
