Yes and excessive logging also hurts performance. regards Malcolm Edgar
On 9/25/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > 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 >
