cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Cocoon CLI] logging with Treeprocessor too verbose
Date Tue, 09 Jul 2002 17:45:56 GMT

Sylvain Wallez wrote:
> 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 ?

Yup :-)

> 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.

This is basically what I mean, yes :-)

>> How can we do iut with CLI?
> "iut" ? Sorry, I don't know this acronym...


how can we do it with CLI?
It simply uses a loglevel AFAIK... looking...
it does... now but looking in the Main class...

         new CLOptionDescriptor("logKitconfig",
                                "use given file for LogKit Management 

So it can be done :-)

>>> 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.


Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message