BIND 10 #2445: suppress initial log

BIND 10 Development do-not-reply at isc.org
Wed Dec 5 18:23:08 UTC 2012


#2445: suppress initial log
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  jelte
                Type:  defect        |                       Status:
            Priority:  medium        |  reviewing
           Component:  Boss of BIND  |                    Milestone:
            Keywords:                |  Sprint-20121218
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:14 jelte]:

 Okay, I realize I didn't fully understand how the logging
 initialization and reconfiguration work.  Now I've taken a closer look
 at the implementation, and with my revised understanding I'm still not
 convinced a singleton must be inevitably used (meaning other
 alternatives would rather be considered much worse).

 > While I work on the smaller points, let me first comment on two of your
 larger points, since they are somewhat related, and chosen for a reason:
 >
 > 1. Singleton buffer
 > 2. Replacing appenders on specification with empty output options list
 >
 > Currently, behaviour does change on the Impl class level (see below,
 > i'm changing that back), but not on the public API, because (and
 > this is kind of obfuscated by the pimpl implementation; the outer
 > calls contain extra lines of code), in logger_manager.[h|cc]'s
 > existing processSpecfication() calls, the entire logging system is
 > reset; all appenders are destroyed, and new defaults are created
 > (for the root logger). And then it starts working through the
 > specification(s) for the actual logger(s).

 I'd like to clarify a few things here.

 First, by "existing processSpecfication() calls" I guess you actually
 meant `LoggerManager::process()` calls (except for the one you added
 in this branch), which call `processInit()`, which calls
 `LoggerManagerImpl::processInit()`, which calls
 `LoggerManagerImpl::initRootLogger()`, where some default values for
 `b10root` logger object are reset.  But, in my understanding,
 `initRootLogger()` shouldn't destroy existing appenders in `b10root`
 at this point.  Note that `log4cplus::Logger::getInstance()` returns
 an existing logger if one exists.

 Secondly, in `LoggerManagerImpl::processSpecfication()`, existing
 appenders for the specified name of logger can be destroyed, but (in
 the original version before this branch) it seems to happen only if
 output options are given.

 > So the reason I put it in a singleton was to not have to collect all
 possible bufferappenders and keep them around before the call to
 processInit() in loggermanager.h's process() calls; otherwise either
 processInit() would need to change; and in that case behaviour would
 change, since it would no longer automatically support *removing* loggers
 from your specification (they'd remain unchanged), or alternatively, it
 would have to make lists of loggers and bufferappenders before and after
 the change and then go through them, which I suspect would be more brittle
 than this is :)

 Here I'm afraid I don't understand...what do you mean by "no longer
 automatically support removing loggers"?  In my understanding (as I
 said above), there's no current behavior of "automatically removing
 loggers", either in `processInit()` (which actually doesn't touch
 existing ones except for the default log level etc on the root) or in
 `LoggerManagerImpl::processSpecfication()` (unless output options are
 specified).

 With my revised understanding, our goal seems to be reasonably
 achievable by extending processInit():

 {{{#!cpp
 void
 LoggerManagerImpl::processInit() {
     // b10root should exist in the context where this method is called
     log4cplus::Logger b10root = log4cplus::Logger::getInstance(
                                                     getRootLoggerName());
     SharedAppenderPtr buffer_appender = b10root.getAppender("buffer");
     if (buffer_appender) {
         // BufferAppender::flush() is an extension, which would flush the
         // internal buffer
         dynamic_cast<BufferAppender&>(*buffer_appender).flush();
     }

     log4cplus::Logger::getDefaultHierarchy().resetConfiguration();
     initRootLogger();
 }
 }}}

-- 
Ticket URL: <http://bind10.isc.org/ticket/2445#comment:15>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list