Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 43497 invoked from network); 23 Apr 2002 00:55:36 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Apr 2002 00:55:36 -0000 Received: (qmail 14110 invoked by uid 97); 23 Apr 2002 00:55:44 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 14076 invoked by uid 97); 23 Apr 2002 00:55:43 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 14062 invoked from network); 23 Apr 2002 00:55:42 -0000 From: Subject: Logkit: Preventing the DefaultLogkitManager from creating the target if it does not exist To: "Avalon Developers List" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 22 Apr 2002 17:40:11 +1000 X-MIMETrack: Serialize by Router on HIC-CO-SMTP-1/SRV/HIC(Release 5.0.9 |November 16, 2001) at 23/04/2002 10:39:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 available; (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. -1 Looking at (3), I thought that this was a trivial subclass and probably just confuses the poor developer. -1 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: For additional commands, e-mail: