Return-Path: Delivered-To: apmail-jakarta-log4j-user-archive@apache.org Received: (qmail 85537 invoked from network); 30 May 2002 16:07:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 May 2002 16:07:24 -0000 Received: (qmail 22454 invoked by uid 97); 30 May 2002 16:07:20 -0000 Delivered-To: qmlist-jakarta-archive-log4j-user@jakarta.apache.org Received: (qmail 22356 invoked by uid 97); 30 May 2002 16:07:19 -0000 Mailing-List: contact log4j-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Users List" Reply-To: "Log4J Users List" Delivered-To: mailing list log4j-user@jakarta.apache.org Received: (qmail 22341 invoked by uid 98); 30 May 2002 16:07:19 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-Id: <5.1.0.14.0.20020530175944.03359458@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 May 2002 18:07:23 +0200 To: "Log4J Users List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2 In-Reply-To: <00b901c207f0$856d3f30$7b0a140a@MADONNA> References: <5.1.0.14.0.20020530095024.020a0448@mail.qos.ch> <5.1.0.14.0.20020530162116.020da888@mail.qos.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N If MyLogger introduces a new method that your code uses, then your code is tied to MyLogger. It is *expecting* to use a MyLogger instance. Your code won't work with any other Logger class. At the same time, when you write Logger l = Logger.getLogger() you don't actually know the type that is returned. It may well be an instance of EnhancedLogger with a totally different logging behavior. You just don't know and don't have to care as long as you strictly adhere to the methods available in the Logger class. At 17:41 30.05.2002 +0200, Giuseppe Madonna wrote: > > >However I wonder, to avoid Logger subclassing, why not make it final? > > >But it was just a thought... > > > > Logger class is not final because Logger sub-classing allows very > > important enhancements such as security or transparent logging domains. > > Domains are a "secret" feature planned for log4j 1.3. > > > > The important point to note is that these sub-classes do not change > > the Logger interface, that is the set of methods available to the > > user. Sub-classing Logger by adding new logging methods is strongly > > discouraged because code written for such loggers will simply not run > > in environments where the enhanced Logger sub-classes are used. (I am > > thinking of Application Servers and Servlet Containers.) > > > > Does it make any sense? > >I'm missing the point. >Code will run fine anyway. >This is java, not C++ and (dynamic) linking is done at runtime, not at >compiletime. >If I extend from Logger class, e.g. MyLogger, code referring to MyLogger >methods will run fine >with log4j 1.999 version in which there will be a EnanchedLogger class >extending from Logger. >If you want to preserve public interface, you can (must) use java Interface >concept. >If you want to make new improvements and make it available to users, you can >(must) extend your old interface. >Application written for old interface are preserved and will runs fine: >backward compatibility is granted. >Who wants to use new enanchements will refer to new Interface. > >Best regards, >Giuseppe. > > > > > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: -- Ceki SUICIDE BOMBING - A CRIME AGAINST HUMANITY Sign the petition: http://www.petitiononline.com/1234567b I am signatory number 22106. What is your number? -- To unsubscribe, e-mail: For additional commands, e-mail: