logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <mwom...@apache.org>
Subject Re: [COMPATIBILITY] DOMConfigurator
Date Tue, 03 Jan 2006 17:27:14 GMT
If I understand you right, this is what I am planning to do.

The new Plugin/Watchdog functionality splits the whole "watch" stuff
into a different heirarchy of classes that perform the watching stuff.
 In the process it becomes much more flexible and controllable and can
now "watch" lots of different types of sources than just files.

The old configureAndWatch methods are going to be re-implemented to
use the new FileWatchdog class and the methods themselves will be
marked as deprecated.  The static configureAndWatch methods will only
allow one FileWatchdog at a time, which will shutdown gracefully when
log4j is shutdown (part of the new Plugin code).  There is a nasty bug
in 1.2 where you can inadvertently set up multiple watch threads and
have no way of ever shutting them down.

So, the basic functionality will be preserved (with some improvements)
and pointers to the new code will be provided.


On 1/3/06, Endre StĂžlsvik <Endre@stolsvik.com> wrote:
> 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

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

View raw message