Given that i seem to have at least a small consensus, i've added a relevant wiki page (please feel free to enhance and edit) and am moving forward with the code changes. If consensus changes, it should be quick to undo or adjust these things.
On 9/24/07, Malcolm Edgar <[EMAIL PROTECTED]> wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
