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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
