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:  stephen
  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      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => stephen


Comment:

 Replying to [comment:3 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 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.

 Handled all these points. Also took example from 1040, and put the
 messages in alphabetical order, and removed some redundant whitespace. And
 expanded the one abbreviation.

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

 Actually it should already have been removed, did so now.

 > 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.
 >

 Hmm, I did a few, though haven't changed them that much. This may also be
 related to my comment below;

 >
 > 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.

 Since we decided that we'd first do the conversion, and then improve the
 result, I was going to defer this to the followup improvement ticket. But
 I do have some thoughts about this; I do not think that is the right
 approach. For some of the current messages, it is hard to tell the
 specific problem, because it is logged too deep; say you have a method
 'parseFoo(str): <dostuff> return FooObject() or raise BadFOO(str)' which
 whould parse a string containing a Foo value, and it finds the string in
 error, that function is not the one that should log the error, since it
 does not know the context in which Foo is needed, or where it came from,
 and neither would the exception that is raised. So the exception should
 not log it either, the right place to log is where the exception is caught
 (in general, that is. I'm sure there are specific counterexamples).

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