On Fri, 28 Dec 2001, 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 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. > > OK. TEAM, your votes about adding fine-grained categories in > sitemap.xmap and cocoon.xconf as described above ? > > +1 from me.
+1 > > > > 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 > http://www.servidium.com/site/logfactor5/index.html) 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). No flooding of many different files for each category seems ok for me. > > > 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. Ok, I've reduced from WARN to DEBUG and will commit it soon into C2. Giacomo > > > Giacomo > > > > > > > > Thoughts ? > > > > > > Sylvain. > > > > > > > -- > > > > Torsten > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
