cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Cocoon CLI] logging with Treeprocessor too verbose
Date Tue, 09 Jul 2002 16:23:59 GMT
Nicola Ken Barozzi wrote:

> Sylvain Wallez wrote:
>> Nicola Ken Barozzi wrote:
>>> Before treeprocessor, the CLI just said what it was traversing
>>> and made good output for the user.
>>> Now on level -INFO there are so many messages that I have to turn it 
>>> off completely.
>>> Should we revert the behaviour?
>> Remember our discussion on log levels : debug is for debugging the 
>> class (i.e. targeted at developpers) while info is to know what the 
>> class does.
> Yup.
>> In the case of the sitemap engine, logging an info message when a 
>> matcher matches helps the user to know the path taken in the sitemap 
>> to process a request.
>> IMO, this kind of info isn't needed in CLI, so I would raise the 
>> default CLI log level to warn.
> Warn gives no clue to the user of what is happening...
> I'm asking you for a suggestion, since in the loglevel there is no 
> user-info level, and maybe it's not to be given to the logger 
> anyway... or just make another logging cat for the user and use that.

Ah, I understand. You would like to distinguish some high-level info 
messages ("Processing foo.html") from low-level info messages ("matched 
pattern '*.html' at sitemap.xmap:123"), right ?

Having a logging category for user messages isn't the way to go, as you 
will end up with a lot of messages there what you won't be able to 
filter. Typically, the two messages above should go in this category and 
finally this doesn't solve the problem.

What about using several subcategories in the sitemap, such as 
sitemap.engine (high-level info), sitemap.engine.matcher (matcher info), 
etc ? This would allow to specify in a CLI-specific logkit.xconf the 
exact messages you want to have.

> How can we do iut with CLI?

"iut" ? Sorry, I don't know this acronym...

>> What do you want to remove ? The stacktrace or the whole message when 
>> a broken link is encoutered ?
>> I'm -1 for removing the whole message : it's bad to ignore broken 
>> links. If you don't see them, you may deploy broken pages on a live 
>> site.
> Sure, it's the stacktrace I'm talking about.

So +1 for removing the stracktrace.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message