Project

General

Profile

Actions

Task #4580

closed

Reimplement NFD logging using ndn-cxx logging facility

Added by Junxiao Shi about 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Low
Category:
Core
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Related issues 1 (0 open1 closed)

Blocks NFD - Bug #2548: Logger: race condition between isEnabled and setLogLevelClosedDavide Pesavento

Actions
Actions #1

Updated by Junxiao Shi about 6 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 50

https://gerrit.named-data.net/4676

20160721 call decided that NFD logging is to be kept separate and not use ndn-cxx logging facility. It's necessary to reconsider this position before deciding whether to merge the above Change.
I personally support adopting ndn-cxx logging in NFD.

NLSR had a successful adoption of ndn-cxx logging.

Actions #2

Updated by Davide Pesavento about 6 years ago

  • Tracker changed from Feature to Task
  • Status changed from Resolved to Feedback
Actions #3

Updated by Alex Afanasyev about 6 years ago

Junxiao, you are citing a two year-old decision. Probably it was meaningful back then, as it stands right now, NFD's logging has a duplicative implementation and I would definitely support unification (= merging the commit).

@Davide. You mentioned that printing logging would not work because they are lazily instantiated. Does it apply to modules loaded from shared library (e.g., ndn-cxx log modeuls) or to everything? It is not critical function, but could be useful in some cases.

Actions #4

Updated by Davide Pesavento about 6 years ago

Alex Afanasyev wrote:

@Davide. You mentioned that printing logging would not work because they are lazily instantiated. Does it apply to modules loaded from shared library (e.g., ndn-cxx log modeuls) or to everything? It is not critical function, but could be useful in some cases.

Everything. It's actually a major problem because nfd --modules doesn't work anymore. Also, ndn::util::Logging::getLoggerNames() is effectively useless as it will give random results depending on which loggers have already been used by the program.

Actions #5

Updated by Davide Pesavento about 6 years ago

  • Status changed from Feedback to Code review
  • Priority changed from Normal to Low
  • % Done changed from 50 to 100
Actions #6

Updated by Davide Pesavento about 6 years ago

  • Blocks Bug #2548: Logger: race condition between isEnabled and setLogLevel added
Actions #7

Updated by Junxiao Shi almost 6 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF