logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre StĂžlsvik <En...@Stolsvik.com>
Subject Re: [COMPATIBILITY] DOMConfigurator
Date Tue, 03 Jan 2006 10:27:14 GMT
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 


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

View raw message