harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][logging] Best practices for logging within the Class Library?
Date Fri, 06 Oct 2006 03:07:59 GMT


Nathan Beyer wrote:
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>>
>> Tim Ellison wrote:
>>> 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?
>> Darn it!  I was hoping that I could beat you to this, by playing the
>> "straight man" and setting you up so you could say this line, because I
>> *knew* you would say this :) [and I agree]
> 
> So does this mean that I delete all of the TODOs with comments like "log
> warning" and not get flamed again?

That wasn't a flame :)

> 
> Seriously, if this was already agreed upon, then why are they tons of
> comments about logging to be reinserted? These comments are either in the
> form of TODOs, FIXMEs and in many cases just logging code that commented
> out.

To be honest, there never was a real consensus reached on it.  I had 
proposed thinking about it from other angles, such as aspects.  I was 
also thinking that some kind of pre-processing might help here - 
developers want it, but we clearly don't want it in a shipped version...

> 
> As for not remembering the previous agreement, sorry about that. I looked
> and the original conversation was in May, I can barely remember last week.

Last week?  I have trouble with yesterday.

geir

> 
>>> 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.
>> Oh, for that #define I was talking about in the sync object thread.
>>
>> Actually, I'll start a new thread on this...
>>
>>> [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?
>>>>
>>>> -Nathan
>>>>
>>>> [1]
>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Level.html
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message