BIND 10 #747: Conversion of server common library to use the new logging interface

[BIND 10 Development]

#747: Conversion of server common library to use the new logging interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  stephen
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110712
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  4.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]:
 > '''src/lib/log/log_formatter.h'''
 > Should add a header to the new method.  (And to be consistent for the
 Doxygen output, both this and the string specialisation
 > of the "arg" method should include documentation of the parameter and
 the return value.)

 I forgot the header before.

 But, isn't it duplicate, if it just simply says it is a version of that?
 Doesn't that say enough about what it returns? I know good documentation
 is needed, but does it help to copy-paste it around?

 > '''src/lib/server_common/server_common_messages.mes'''
 > The message ID prefix SRV_COMMON_ .  As it contained the underscore, I
 was reading message IDs like SRV_COMMON_ADDRESS_MISSING as "prefix SRV, ID
 is COMMON_ADDRESS_MISSING" and wondering what a common address was.  I
 would suggest using something like SRVCOMM_ as the prefix.

 OK. And it's actually shorter.

 > SRV_COMMON_ADDRESS_FAIL
 > Can we identify what address/port the failure was on?  At the moment the
 message only lists the exception text - will that contain the necessary
 information?  Also, the description suggests that the server was listening
 on a port before.  Perhaps the text should mention that this message is
 the result of a configuration update?

 Well, it would be hard to identify at that point of code, because it's not
 stored there anywhere. It could be possible to change it, but it would be
 quite severe restructuring of the current code and exception handling.
 Should it be done at the logging „conversion“?

 > SRV_COMMON_ADDRESS_UNRECOVERABLE
 > which it is running.  The server will continue running with any other
 > configured addresses although the service may be severely degraded.

 Isn't it British version of well-known kernel "OOPS"? ;-)

 I modified it a bit, because it wasn't quite clear the server will not be
 listening on anything at all (which probably can be categorized as
 severely degraded) and how to fix it.

 > SRV_COMMON_KEYS_UPDATE
 > Should be "...is initializing the global TSIG keyring."

 I also noticed I switched two descriptions by accident.

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