cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Cocoon CLI] logging with Treeprocessor too verbose
Date Tue, 09 Jul 2002 17:55:08 GMT
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> 
> 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.

Can we have some intermediate log level, between INFO and DEBUG? It
would be *really* nice to have some general info on INFO level, some
useful to the user info on intermediate level, and class level debug
info on DEBUG level.


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

+1, and I would love to see above suggestion implemented too.


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

No objection if ResourceNotFound is not abused anywhere; otherwise
stacktrace will be required to track bugs. Can stacktrace be printed
only when debug level is enabled and short info message when it is not?


Vadim


> Sylvain
> 
> --
> Sylvain Wallez
>   Anyware Technologies                  Apache Cocoon
>   http://www.anyware-tech.com           mailto:sylvain@apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message