cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernhard Huber" <>
Subject Re: [vote] Finer-grained logging categories (was: Re: Over-Logging)
Date Sat, 29 Dec 2001 05:52:29 GMT
+1 from me.

Sylvain Wallez wrote:

>giacomo a écrit :
>>On Fri, 28 Dec 2001, Sylvain Wallez wrote:
>>>Torsten Curdt a écrit :
>>>>>Now that I am back working with Cocoon, I have recently come to the conclusion
that DEBUG
>>>>>simply outputs too much information.  For one (1) request, Cocoon outputs
23 pages of
>>>>>log messages equivalent to 57k on the drive.
>>>>>My friends, this is too much.  Logging should have a purpose, and not
simply spout information
>>>>>for information's sake.  I am trying to track down what is going on in
the XSP engine,
>>>>>and I have to sift through 57k of messages.
>>>>I like to second that
>>>>>Principal of Diminishing Returns
>>>>>It is important to understand the principal of diminishing returns.  Basically,
it boils
>>>>>down to the concept that 90% correctness only takes 10% of the effort.
 It is that last
>>>>>10% of correctness that takes up the remaining 90% of the effort.  Our
logging has reached
>>>>>critical mass.  By logging anything and everything, we have an unusable
>>>>>I am not sure what needs to be done.  Some categories need to be logged,
while others
>>>>>do not.  It all depends on what you are tracking down.  We need to have
more folks
>>>>>understand the LogKit configuration file, so that we can have a much finer
>>>>>control.  Since it is a major point of Cocoon's configuration Cocoon needs
to document
>>>>>it in the xdocs.  The inline comments are not very clean, perhaps we need
>>>>>that demarcate the beginning and ends of the comments.
>>>What do you mean by "separators that demarcate..." ? A special formatter
>>>that adds linefeeds in the log file ?
>>>We may also remove some debug messages : many of them were used to debug
>>>components during their writing, and they aren't useful anymore now that
>>>they are stable.
>>>>So you like to get rid of this mess by configuring logkit?
>>>>Actually I'm wondering if we have enough categories
>>>>to really get back to a fine grained control this way.
>>>We can add more categories : in my sitemaps, each component has a
>>>different category (using the "logger" attribute) :
>>This is what it was originally proposed to be used for. I wasn't willing
>>to go this far for the version we distribute with the CVS and releases
>>but we can vote to have this in CVS.
>>>This leads to a fine-grained hierarchical classification of categories
>>>which allows to easily track messages in a particular area. This is also
>>>applicable to components in cocoon.xconf.
>OK. TEAM, your votes about adding fine-grained categories in
>sitemap.xmap and cocoon.xconf as described above ?
>+1 from me.
>>Do you log those messages  into one file or different file (prob. one
>>per category?)
>I use two targets : one file for all messages, and a target I've written
>for a commercial swing GUI (see
> which has a nice
>handling of log hierarchies.
>Fine-grained categories allows to quickly find messages output by a
>particular component and having a single file allows to easily consult
>other related logs (e.g. all log messages for a given request).
>>>If you like this approach, I can add it in the CVS.
>>I'm not sure about it so +0.
>>>The only drawback is that LogKit complains about categories not
>>>explicitly declared in logkit.xconf. Maybe LogKit shouldn't be so picky
>>>about that and just act as a configuration front-end to Hierarchy (i.e.
>>>remove the m_loggers HashMap).
>>This can be fixed (I wrote it) but IIRC it's a debugging (or should
>>be) message and thus might be helpfull in that aspect.
>I would be thankful if you fix it, because it produces a _warning_
>message each time a component asks for a logger that's not in the
>configuration-defined categories.
>>>Thoughts ?

To unsubscribe, e-mail:
For additional commands, email:

View raw message