I wish to highlight again the logging policy on the framework as I
noticed not all modules are following the policy and we must remedy to
this mistake.
I used verbs CAN, SHOULD, MUST and SHOULD NOT as they are used in the
RFCs.... just to get it as much clear as I can....
Please add your opinions and contributions if I left any condition
uncovered, this can help writing a style guide
- methods entrance SHOULD be logged with info level for business
methods (thus on the domain), web requests (thus on the Action
methods) and persistance calls (thus on factories) and this logs
should bring parameters name and value
- methods CAN log additional informations using debug level or trace
level depending on how much datas should be logged
- logs of level beyond info (thus debug and trace) must be wrapped
with an if statement to check if the log level is enabled (otherwise
performance issues can be raised)
- logs MUST be composed with the method signature, an hyphen and an
additional lower case informative and brief string
for ex.
logger.info("myMethod(param1=" + param1 + ", param2=" +
param2 + ") - start");
logger.info("myMethod(param1=" + param1 + ", param2=" +
param2 + ") - something happened");
- logs of level beyond info (debug and trace) SHOULD NOT bring the
method signature unless they span a long time and should be indented
(\t) against other logs
for ex.
if (logger.isDebugEnabled()) {
logger.debug("\tparam1 has value " + param1);
}
if (logger.isTraceEnabled()) {
logger.trace("\tparam1 has value " + param1);
logger.trace("\tparam2 has value " + param2);
logger.trace("\tparam3 has value " + param3);
}
- exceptions SHOULD be logged ONLY IF NOT RETHROWN, in case you rewrap
the exception you CAN log the exception at a debug level
--
Roberto Lo Giacco
|
