Return-Path: 
 <log4j-dev-return-11709-apmail-logging-log4j-dev-archive=logging.apache.org@logging.apache.org>
Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org
Received: (qmail 37944 invoked from network); 3 Jan 2006 10:27:39 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 3 Jan 2006 10:27:39 -0000
Received: (qmail 47136 invoked by uid 500); 3 Jan 2006 10:27:39 -0000
Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org
Received: (qmail 46874 invoked by uid 500); 3 Jan 2006 10:27:38 -0000
Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:log4j-dev-unsubscribe@logging.apache.org>
List-Help: <mailto:log4j-dev-help@logging.apache.org>
List-Post: <mailto:log4j-dev@logging.apache.org>
List-Id: "Log4J Developers List" <log4j-dev.logging.apache.org>
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Delivered-To: mailing list log4j-dev@logging.apache.org
Received: (qmail 46862 invoked by uid 99); 3 Jan 2006 10:27:37 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2006 02:27:37 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [212.33.142.3] (HELO challenger.coretrek.no) (212.33.142.3)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jan 2006 02:27:36 -0800
Received: from enterprise.intra.coretrek.com (wormhole.coretrek.no
 [212.33.142.10])
	by challenger.coretrek.no (Postfix) with ESMTP id 2C39EF8F00
	for <log4j-dev@logging.apache.org>; Tue,  3 Jan 2006 11:27:14 +0100 (CET)
Date: Tue, 3 Jan 2006 11:27:14 +0100 (CET)
From: =?iso-8859-15?Q?Endre_St=F8lsvik?= <Endre@Stolsvik.com>
X-X-Sender: endre@enterprise.intra.coretrek.com
To: Log4J Developers List <log4j-dev@logging.apache.org>
Subject: Re: [COMPATIBILITY] DOMConfigurator
In-Reply-To: <003301c61009$8ca19e70$4001a8c0@hogwarts>
Message-ID: <20060103110637.J50662@enterprise.intra.coretrek.com>
References: <003301c61009$8ca19e70$4001a8c0@hogwarts>
X-My-Opinion: War and bombs are bad. Peace and flowers are good. ;-D
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

On Mon, 2 Jan 2006, Mark Womack wrote:

| I was looking at this class in regards to compatibility with 1.2.  I was
| interested in restoring the configureAndWatch methods. 

I personally truly dislike libraries that fork threads as a "side effect" 
of invoking "some random method", or even worse just by using some class. 
It is simply a hideous mess that make memory leaks and other nasty 
annoyances impossible to understand and debug.
  So, I definately feel that using any method of a core API should not 
fork any threads, even if it is specified in <h1>-tekst on the javadoc. It 
_will_ make problems for log4j's users, I believe.

  (Underlying point is that developers doesn't start out fully educated, 
and such methods will look tempting and unconspicuous, and one won't 
understand the implications.)

I suggest that this should be split into a "Utility class" that one might 
use by going to a totally separate package, which kinda hooks into the 
configurator and does this watching for you. If this isn't possible now, 
then make it possible using some interface methods on the configurator. 
This object should have a _clear_ method for "shutdownWatcherThread" or 
similar, which also the configurator itself should invoke if it is 
"restarted" or shutdown or whatever.

Make the old methods @deprecated, and then let them do a normal 
once-configure to restore a binary, if not full functional backwards 
compliance.

Regards,
Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org