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 mess.
> > >
> > > 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 
>grained
> > > 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 
>separators
> > > 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) :
>
> sitemap.generator.file
> sitemap.generator.directory
> sitemap.generator.serverpages
> sitemap.transformer.xslt
> sitemap.transformer.log
> sitemap.serializer.xml
> sitemap.serializer.html
> sitemap.matcher.wildcard
> ...

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.

Do you log those messages  into one file or different file (prob. one
per category?)

> 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.

Giacomo

>
> Thoughts ?
>
> Sylvain.
>
> > --
> > Torsten
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to