You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/07/09 17:27:54 UTC
[Cocoon CLI] logging with Treeprocessor too verbose
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?
Also, each broken link shows a stacktrace, which really sucks.
Is it ok if we remove it?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Cocoon CLI] logging with Treeprocessor too verbose
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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...
it
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",
CLOptionDescriptor.ARGUMENT_REQUIRED,
LOG_KIT_OPT,
"use given file for LogKit Management
configuration"),
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Cocoon CLI] logging with Treeprocessor too verbose
Posted by Vadim Gritsenko <va...@verizon.net>.
> 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
Re: [Cocoon CLI] logging with Treeprocessor too verbose
Posted by Sylvain Wallez <sy...@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.
>
>
> 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
--
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
Re: [Cocoon CLI] logging with Treeprocessor too verbose
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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.
How can we do iut with CLI?
>> Also, each broken link shows a stacktrace, which really sucks.
>
> It's broken links that suck ;)
hehehe
>> Is it ok if we remove it?
>
> 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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Cocoon CLI] logging with Treeprocessor too verbose
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
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.
> Also, each broken link shows a stacktrace, which really sucks.
It's broken links that suck ;)
> Is it ok if we remove it?
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.
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