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).
> 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.
>
> If you like this approach, I can add it in the CVS.
+1
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
