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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
