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
