avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <david.g...@hic.gov.au>
Subject Logkit: Preventing the DefaultLogkitManager from creating the target if it does not exist
Date Mon, 22 Apr 2002 07:40:11 GMT

I prefix my comments by stating that, yes I know that DefaultLogKitManager
is deprecated but the comments apply equally to the replacement
LogkitLoggerManager to the LogkitLoggerManager. I have included both names
in the following discussion.

I have a requirement that the Manager should not create a logger if it does
not exist in the XML configuration. Basically I want to ensure that every
log message is accounted for and sent to the correct location.

I propose 3 possible solutions to implement the above:
(1) change the constructors so that a new property "boolean createNew" is
(2) add a property to allow the setting/getting of the property;
(3) subclass the sucker to provide classes that provide the 2 different
behaviours (create a new one or return an null/exception); and/or
(4) pass in a boolean createNew when requesting the logger

Looking at (1) I determined that we then need some 7 constructors to handle
the various combinations of Hierarchy, Prefix and createNew. I thought that
this is a little out of hand.


Looking at (3), I thought that this was a trivial subclass and probably
just confuses the poor developer.


So for (2).The problem I see here is that the interfaces LogKitManager /
LoggerManager does not throw an exception on the getLogger/getLoggerForName
methods. I could implement the function so that it just returns null but
NPE can be very confusing to the client application especially if the
developer does not code the checkForNull. What I really would
like is to change the interface (gasp) to throw an exception but am
prepared to settle to catch the null in my application code (I have only
one place where I call the method) but this may not work for others.
I am also aware that the mehod is
probably called from many places in the hierarchy. Also the semantic
distance between the setCreateNew method and the getLogger makes this less
than intuitive.

Now (4) is also possible but it still requires an additional change to the
interface but is more obvious than (2).

Any suggestions?

NOTICE - This message is intended only for the use of the 
addressee named above and may contain privileged and 
confidential information.  If you are not the intended recipient
of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it.  If you 
received this message in error please notify HIC immediately.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of HIC.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message