Bug #3782
closed
Logging facility conflicts with app using Boost.Log
0%
Description
As discovered in #3761, when two sinks are added to Boost.Log, messages will appear twice or scrambled on OS X platform.
NFD avoids the problem by letting ndn-cxx initialize Boost.Log.
However, if an application directly uses Boost.Log and adds its own sink, it would still conflict with ndn-cxx logging facility and cause messages to appear twice.
Updated by Junxiao Shi about 8 years ago
- Blocked by Bug #3761: Duplicate/scrambled characters in log message added
Updated by Alex Afanasyev over 5 years ago
I would like to close this old issue. It is a known issue, but I don't think there is any solution to this.
If ndn-cxx based app wants to do its own init of the sink, it needs to set a "null" destination before doing anything else. I guess, the only we can do here is to simply provide a simpler way to set such a "null" sink.
If app is not ndn-cxx based, it doesn't have the issue.
The only real problem would be for the app that uses the library that uses ndn-cxx (i.e., the app doesn't directly interact with ndn-cxx). Don't think this would be easily solvable and even in that case app still kind of aware of ndn-cxx existence and can do smarter things with the log init.
Updated by
Updated by Junxiao Shi over 5 years ago
If ndn-cxx based app wants to do its own init of the sink, it needs to set a "null" destination before doing anything else.
Please give an example of how to do this, either in the codebase as a test case or example, or on this Redmine page. Then the issue may close.
Updated by Alex Afanasyev over 5 years ago
- Status changed from New to Code review
https://gerrit.named-data.net/#/c/ndn-cxx/+/5520/
Example of this would be to call Logging::replaceLogger(nullptr);. However, as I just described in gerrit, Boost.Log has some "interesting" default sink that kicks in when all custom sinks are removed. I'm observing output like
[2019-07-13 12:26:17.830211] [0x000000011d8055c0] [info] fatal1
I think we can live with this, as it still addresses the problem of this issue and allows effective replacement of the log sink to anything that application desires.
Updated by Alex Afanasyev over 5 years ago
- Assignee set to Alex Afanasyev
- Target version set to 0.8.0
In the latest patchset, the API for this changed (=simplified) to just Logging::setLogger(nullptr);
Updated by Alex Afanasyev over 4 years ago
- Status changed from Code review to Closed
I am closing. We have provided API to turn off when needed and nothing else we can do.