* Nat Goodspeed
Mojmir Svoboda wrote:
no he will _NOT_, that is the beauty ;)) if he still do, let him use log4jpp. according to my (i admit that short perhaps) experiences, this is very rarely needed. you can either modify source and recompile or use log4j++ like i said.
My experience is with large products with many subsystems, worked on by many developers over the course of years.
hmm, i've been few years in telco, so i have the picture. blurred may that one be ;)
The most effective logging machinery:
- Allows you to turn on logging at runtime, so your support person in
of course, that is necessary.
- Has trivial runtime cost for a suppressed log message... runtime cost is nothing more than examining a static bool and a jump.
this is related to 1st and i second that.
- Allows you to be selective about what logging output is produced, because if you turn on EVERYTHING, your user has trouble even storing and mailing you the resulting file -- never mind your problems trying to discover what might be relevant. (This is the result of accumulating helpful logging output in many interacting subsystems over the course of years.)
i know, logs can be really huge. but i never meant to not provide what you call runtime filtering. i perhaps said something badly. i thought you wanted add another filter at runtime. what i am saying is: User is not allowed to change format of the logged text at runtime, by changing the formatting chain. i know it can be done, but i don't want to as i consider it unnecessary. the reason why is that as you have large codebase with lot of outputs, your people probably have tools helping them analyse the logs: regexps, indents, scripts, filters to gnuplot etc etc. if you change order of the logged columns, your tools are confused. my approach is simply: think before picking format and then let it be the same forever (or at least for some long period). as a library user you can change it during development of course, but to take place, you have to recompile. i hope that is clear, now and sorry for confusion i made.
There are probably people for whom compile-time controls suffice. But such a library wouldn't be useful to our developers.
see above: compile-time approach fixes only the order of filters, it does not disallow runtime filtering. many thanks for feedback, mojmir