I have been thinking, and one of the previous arguments against Java's Logging API was, "Who needs three levels of debugging?".
In developing with Cocoon, it has become clear that three levels of debugging may in fact be just what the doctor ordered. Let me give you a scenario: Excalibur's ComponentManager and ComponentSelector and friends output _alot_ of debugging code. It is what makes it so easy to maintain. However, I don't want to clutter the logfile with all that information unless I really need to. Therefore I need a base log level for INFRASTRUCTURE, so that I can see the inner workings if I wanted to. Second, in order to track down ClassLoader issues using Excalibur's Factories and Pools, It would be useful to output a message saying "loading class xxxx with ClassLoader Classloader$3242335" at a higher level. That way by placing this type of information at an CLASSLOADER priority, I can easily filter it out--but I have it if I need it and I don't have to troll through all the INFRASTRUCTURE level entries to find them. Last, we would need an APPLICATION level debugging to differentiate between Cocoon's DEBUG information and Avalon's. This way, I don't have to artificially upgrade Cocoon's logging entries on new components while I am developing them. Using that approach I record the component's log entries at INFO--unless I catch an exception which has to be at DEBUG or WARN and above. This is not desireable to me. Peter, what do you think of adding two additional log levels below DEBUG in LogKit? The new hierarchy of debug levels would be: INFRASTRUCTURE CLASSLOADER DEBUG INFO WARN ERROR FATAL_ERROR Alternatively, we could call them DEBUG3 and DEBUG2 respectively, but it does not capture the intent of those log levels properly. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
