BIND 10 #555: C++ Logging - multiple destinations and configuration

[BIND 10 Development]

#555: C++ Logging - multiple destinations and configuration
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  stephen
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110614
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  8.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => stephen


Comment:

 Hello

 Replying to [comment:8 stephen]:
 > > In several conversion functions, when it gets invalid input, it
 returns something anyway and logs a warning. Is there any reason for such
 behaviour?
 > It is for robustness - I didn't want BIND10 falling over if someone made
 a spelling mistake in the configuration file.  (Also, it follows the Jon
 Postel dictum: "Be conservative in what you send and liberal in what you
 accept".) However, in some places no warning was logged and the error
 silently ignored.  In these places I've logged a message before coercing
 the value. (Throwing an exception was an option, but is many cases is
 likely to result in program termination.  Logging - at least to the
 console - is enabled early on in the program and so is used where
 possible.)

 Well, personally I don't like this kind of robustness, where something
 does something else than what I wanted (and what I think I asked it to do)
 and doesn't really tell me loudly what's wrong. But maybe it's better than
 kill the whole server, admins should have something to parse the logs for
 them and email them or so.

 > > LoggerManager::init says This must be the first logging function
 called in the program. What happens if it isn't? Like if some object is
 statically initialized and uses a function in it's constructor which does
 some logging, therefore it's called before main starts, will it crash, or
 will it just log into some default destination?
 > The consequences have been noted in the header of the init() functions
 in !LoggerManager and !LoggerManagerImpl.  There will be no crash, just
 messages written to stderr that log4cplus has not been initialized.

 The thing that it's dependant on the underlying implementation doesn't
 sound any bit less scary O:-). I just wanted to point out that the
 possibility of logging before full initialization should not scare people
 into not logging.

 > > And, it would be nice to say that the file parameter might be NULL.
 > Done, although it is recommended that this not be the case.

 I didn't mean the name of the logger, I meant the filename of the
 replacement dictionary. I just wanted to make clear note that NULL means
 no dictionary (it's half-implicit in the description right now). It never
 occurred to me that the name of the root logger could be NULL and I don't
 think we want to document that O:-).


 Anyway, do we need the impldef.{h,cc} files in git?

 Thanks

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