Project

General

Profile

log level:scope detailed description

Added by Mario Diethelm 10 months ago

Hello,

where can I find a "log level:scope" detailed description?

Thanks.


Replies (4)

RE: log level:scope detailed description - Added by Christian Meyer 10 months ago

Had a similar Question a while back

https://redmine.emweb.be/boards/2/topics/18076?r=18080#message-18080

Hope this is detailed enough there?

RE: log level:scope detailed description - Added by Mario Diethelm 10 months ago

Understood. Thanks a lot.

Talking specifically about Wt library I have identified some obvious "info:scope" through applications log: info:WebRequest, info:WebController, info:WEnvironment, info:Wt and info:wthttp. Do you have a complete list of all level:scope combinations that the library emits ideally with an explanation of when and why those messages are issued?

Thanks again. Best regards

RE: log level:scope detailed description - Added by Christian Meyer 10 months ago

I do not =)

I am happy to use log:scope for debug messages that I can configure the detail of on the fly and just forget about them when it works.
And then still have them, when I want to upgrade stuff later.

RE: log level:scope detailed description - Added by Matthias Van Ceulebroeck 9 months ago

Hello Mario,

my apologies for the later reply.

Generally speaking internally Wt will use LOG_ERROR, LOG_WARN, LOG_SECURE, LOG_INFO, and LOG_DEBUG. Where often the scope is the name of the main class of the file. The debug level is mostly very verbose, and gives good output during development. It'll often point out what is happening on a low level, and allow developers to trace specific issues. The info level is fairly similar to it, but often less verbose. It will still provide more information on what functionality is being executed, what it results in, or what effects it has, but more succinct than debug.

All other levels (being error, warn, and secure) are considered more "necessary". These often result in log entries where the application got in a weirder state or things are happening where they shouldn't (think of bad input, bad handling, errors occurring, ...).

All of this is with a grain of salt, as deciding what is logged where can often be tricky, and will depend on developer interpretation.

I hope this somewhat answers your question.

Best,
Matthias

    (1-4/4)