My problem concerns logging of library classes (classes that are used inside libraries),
We are currently using log4cxx
but the log4j
library implements the same concepts.
Say i have a process that have several entities, A,B and C. Each of them use many different classes and functions, clearly separated in the code.
A,B and C use many library classes, functions, objects, resources and sometimes even globals (legacy code, nothing i can do about it...) - let us call them all foo
Logging A,B and C turned out to be a performance issue, the log gets blasted when we set the log level to debug. After viewing our system we came to these conclusions:
- We want to be able to change debug level for only one of the classes at a time (or all of them, using root)
- When all kind of
foo
print to log, we need to see which entity called it, A, B or C. - As there are many
foo
we want to be able to change the debug level separately for eachfoo
- A
foo
should be treated as a common library, it can not depend directly on A,B or C. - A,B and C might use the same instance of
foo
(for example, the same instance of our resource handling class is used A,B and C), in the log we would like to see which class usedfoo
. - A could use B (or C), but we dont have to see it in the log...
This is what we came up with so far -
A, B and C will have separate loggers. A global variable(kept in a different library with all of our logging helpers and wrappers) will always keep the current log reporting. Every time an entity starts handling it's logic, it sets the global variable to the proper logger. When a foo
wants to report to the log, it reports through the global variable and adding it's name (and context) to the log message.
Problem is, it feels like there must be something that does this already, the solution does not feel clean, holding a global variable like that...
Are we doing something wrong here? Is there a better solution to this?
info
if notwarn
orerror
. – Craze