BIND 10 #761: Conversion of xfrin to use the new logging interface

[BIND 10 Development]

#761: Conversion of xfrin to use the new logging interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  stephen                            |                Status:  assigned
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110628
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by stephen):

 Overall, the logging looks as I expect.  Just a few comments:

 '''xfrindef.mes'''
 Depending on discussions this afternoon, we might want to get rid of the
 $PREFIX.

 Message text should start with a lower-case character.

 I think that some message descriptions need to be expanded.  For example,
 the description for BAD_ZONE_CLASS paraphrases the message text and does
 not explain why/where the message originated.

 I know I started the convention of calling message files
 xxxdef.<whatever>.  However, I'm now thinking that a convention of
 xxx_messages.<whatever> is more descriptive.

 '''xfrin.py.in'''
 The root logger name is initialized as "b10-xfrin" as is the name of the
 logger used to log messages in the xfrin.py module.  Although this is
 perfectly valid, it does mean that any logger settings aimed at this
 module also affect the settings of the loggers used by the C++ modules
 (unless they have their own settings).  Using a different name for
 xfrin.py logger (e.g. "xfrin") gives finer control: "b10-xfrin" settings
 affect everything that doesn't have its own settings, "b10-xfrin.xfrin"
 affects just this Python module.

 I take it that the DONOTCALLMEEVER is just a place holder?

 Jeremy has commented about multiple errors being attached to one messages.
 The code raises exceptions which are caught and the reason attached to
 them output (although I notice that occasionally an error is logged just
 prior to raising the exception). It might be neater to combine the raising
 of the exception and the logging of the message by raising the exception,
 passing the message code (and parameters) as constructor arguments, and
 having the constructor log the message.  If the exceptions raised here
 were derived from a common base class, the "except" clause in main() could
 distinguish between exceptions where a message has already been logged,
 and one where output needs to be produced.

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