Combes, Chris M. wrote:
Folks,
I have an application which configures my logging system through a
ProperyConfigurator. The application instantiates objects which are
implemented in external DLLs. When instantiation occurs (e.g. in the
constructor of whatever object) the logging configuration is lost. /.../
It looks like whatever log4cxx configuration I use does not carry
over across the DLL boundary.
/../
That behavior would be expected if the application DLL's were linked
with log4cxx static library. To share logging configurations, the
application DLL's must be linked with a log4cxx dynamic library. There
may still be an issue, but please check that you aren't compiling with
statically linked log4cxx.
I have a similar problem with static libraries. I have a bunch of static
libs, which all use log4cxx and declare their own logger hierarchy
(descendant from the main app's logger).
Whenever I log from the main app code, it's all good but when I go deep
into the static lib code, I get an exception.
Tracing it, I saw that the problem is in Logger::getEffectiveLevel().
Looks like it tries to deduce the debugging level when it's not defined
for this specific logger. So it goes up to its parent, up till it gets
to a logger named "root" which has a null parent pointer.
Problem is, this root logger is different from the main app root logger:
different addresses, different data in the fields, namely the debugging
level.
For the classes in the static libs, their loggers are declared as
static. Could this be the problem?
There are no DLLs involved in this situation.
What am I missing?
Many thanks
Dan
|
