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]
