You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@gmail.com> on 2006/10/05 03:46:50 UTC
[classlib][logging] Best practices for logging within the Class Library?
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
Re: [classlib][logging] Best practices for logging within the Class Library?
Posted by Alexei Zakharov <al...@gmail.com>.
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/%3c906dd82e0605301937n55705610w83a32a9783a7d39@mail.gmail.com%3e
Thanks,
2006/10/5, Tim Ellison <t....@gmail.com>:
> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][logging] Best practices for logging within the Class
Library?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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
RE: [classlib][logging] Best practices for logging within the Class Library?
Posted by Nathan Beyer <nb...@gmail.com>.
> -----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?
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.
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.
>
> >
> > 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
Re: [classlib][logging] Best practices for logging within the Class
Library?
Posted by "Geir Magnusson Jr." <ge...@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]
>
> 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
Re: [classlib][logging] Best practices for logging within the Class
Library?
Posted by Tim Ellison <t....@gmail.com>.
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?
>
> -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
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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