cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Over-Logging
Date Fri, 28 Dec 2001 15:58:51 GMT


Berin Loritsch a écrit :
> 
> 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 ?
> 
> No, I was referring to the inline comments in the config files:
> 
> <!--
>     THis is a long description.  It is purposely vague and long to show how
>     a paragraph of text obscures where the markup begins and the comments
>     end.  This is especially the case when we show alternative markups like
>     this:
> 
>     <demo logger="demo"/>
>     <demo logger="prod"/>
> -->
> <demo logger="demo"/>
> 
> When you see constructs like this throughout the config file you get lost
> quite easily unless you have an editor with color coding.  The build script
> and even the Sitemap have lines that mark the beginning and end of the
> comments to provide a visible separator.  The above comment when repackaged
> looks like this:
> 
> <!-- ***********************************************************************
> *  THis is a long description.  It is purposely vague and long to show how
> *  a paragraph of text obscures where the markup begins and the comments
> *  end.  This is especially the case when we show alternative markups like
> *  this:
> *
> *  <demo logger="demo"/>
> *  <demo logger="prod"/>
> *********************************************************************** -->
> <demo logger="demo"/>
> 
> As you can see configuration files can get more readable when comments are
> added in clearly demarcated blocks.  (Of course, as with logging, too many
> comments and you loose the code).

Ok, I understand and agree. Not everybody uses a syntax coloring editor.

> > 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.
> 
> :)  I did that with ExcaliburComponentManager.  I also noticed that there
> were some erroneous messages from the CVS version of ExcaliburComponentManager.
> I fixed it last night, so you won't see "Role Manager wasn't set!" in the
> logs anymore.  It was not only logged in the wrong place, on closer inspection
> of the code there is _always_ a RoleManager installed.  I will update CVS
> soon with the patched version.
> 
> >>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 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.
> 
> That is the next thing I was thinking about.  The Logging categories should
> not be set by the configuration file!  They should be designed in by the
> system.  The configuration file should determine how we deal with the categories.
> I.e. should the logging be turned off (null logger), should it be sent to this
> output file, this set of output files, etc.

Agree : logkit.xconf should describe what to do with categories, but not
define them. That's why I think DefaultLogKitManager shouldn't complain
about categories not defined in its configuration.

> >
> > If you like this approach, I can add it in the CVS.
> 
> +1

Ok, I'll do that.

> I like this approach much better.  It shows that thought was given for the
> system.  It also allows a much more focused logging strategy.
> 
> > 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).
> 
> Maybe.  The whole system is being redone, taking in lessons learned, and
> applying cleaner implementations.  That will assist in the process.  BTW,
> it isn't LogKit that is picky, it is the LogKitManager as LogKit has no
> knowledge of reading a configuration file.

_you_ are picky :) I was of course talking of LogKitManager, and to be
even more picky, about DefaultLogKitManager ;)

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message