Table of contents
...
This should be treated carefully to avoid excessive logging: if the method is simple, or does not require logging (everything is logged in nested methods for example) skip this recommendation. Common layered architecture of a service contains controllers, services and repositories (generated and hand-written). Methods of these classes are a good place to log enter/exit.
This can not be directly applied to reactive-style methods, returning Future objects. In this case, the logging should be done in the code which sets Future result.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
public int sumWithCondition(int a, int b, int cond) {
LOGGER.debug("sumWithCondition:: parameters a: {}, b: {}, cond: {}", a, b, cond);
int sumResult;
if (a > cond) {
LOGGER.info("sumWithCondition:: a > cond");
sumResult = a + b;
} else {
LOGGER.info("sumWithCondition:: a <= cond");
sumResult = cond + b;
}
LOGGER.info("sumWithCondition:: result: {}", sumResult);
return sumResult;
} |
This can not be directly applied to reactive-style methods, returning Future objects. In this case, the logging should be done in the code which sets Future result, e.g. add logging for onSuccess and ensure there is error logging for onFailure.
1.3 Branching and conditions
...
- All log messages must be created using log framework substitution mechanism.
- Complex log message parameters should be created lazily where possible
- Using Pattern Layout, pay attention to the conversion characters you use. See https://www.codejava.net/coding/common-conversion-patterns-for-log4js-patternlayout
...