Well, I still think that logging is useful sometimes.
Is it for our end-users? Do we expect them to turn on logging and look at the contents to discover problems in our code? or perhaps discover problems in their usage of the API? Both of these seem like flawed concepts.
Yes, exactly. For end users. Not to discover problems in our code but to discover problems in their configurations. For example the scenario mentioned by Mikhail L. in [1]. Or with that long-suffering DNS provider. The network conditions may change as time goes by. So users may probably benefit from the knowing why they should wait so long until their request is served. And I also hold the opinion that the debug-level logging is not so bad. In case we can easily remove it from critical parts of the code of course. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] Thanks, 2006/10/5, Tim Ellison <[EMAIL PROTECTED]>:
We did this topic already <g> it's even referenced from the website [1]. So at the risk of repeating my super-super-duper high level view... Why are we considering putting logging into the class library implementation? Is it for our end-users? Do we expect them to turn on logging and look at the contents to discover problems in our code? or perhaps discover problems in their usage of the API? Both of these seem like flawed concepts. Is it for us as developers? Putting printf's in the code doesn't seem like a very efficient way of figuring out how the code works, and just clutters up the codebase. I'd also object to having loads of modules depend on logging. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html Regards, Tim Nathan Beyer wrote: > There seem to be a number of places where logging would be useful > within the class library (and Java parts of the VM), but the rules of > engagement seems to be undefined, so it's not being used. Here's my > super-duper high-level swipe at it. > > 1. Use java.util.logging for normal logging (somewhat obvious). > 2. Do not use java.util.logging within luni, security and kernel > modules; this is to prevent cyclical executions. > 3. Use the class name for the name of the Logger; this is based on the > assumption that classes will be packaged appropriately such that > logging can be enabled by packages to get sub-system information. > 4. Use the java.util.logging.Level javadoc [1] as a guide for the > appropriate logging level for a particular message. When in doubt, be > conservative and use lower levels (less than INFO). > > Thoughts, comments? The big question in my mind is what modules must > be isolated from consuming java.util.logging (regarding 2 above). The > other modules that might need isolation are archive and text, but I'm > not sure about that. Any others?
-- Alexei Zakharov, Intel Middleware Product Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
