I've followed this on both lists and I have to agree with both in certain circumstances. I admit that in my code I have a lot of static instances of loggers, mostly for debug purposes and that in some cases a setLogger() method isn't practical. However there are uses for 'tracing' beyond just the component writers debugging needs. In our product for example, we allow and end user to turn on the logging to see what is going on so that they can debug their portion of the app, namely what goes into the config file. So while 'real' logging probably happens at the service level 95% of the time, it is useful at the low level as well.The fact is not that static accessors solve a need, a *real* need, that is access to a logger for fine-grained components with big hierarchies.
If we solve the need in another way, static accessors may not be needed.
Logging is a want not a need in most cases :-)
Ok, it's called "logging" but it's more "tracing".
Oversimlpifying, Logging should be that thing that records what happens in an app at runtime in a *deployed* environment.
Tracing does it at debug-time. No user of POI would ever care about what POI "logs".
Only the "service" part of POI should log, and that's not many classes, so IOC can be used nicely.
That's why I'm interested in your approach :-)
Having said that, I did start out using LogEnabled and such in our current version of our code, but slowly got rid of it because it seemed a pain at the time of having to maintain two logging configs. Maybe it isn't that hard, but it certainly was a lot easier.
- Robert McIntosh
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
