Robert, I think we should share these thoughts with the authors. That's why I
forwarded it.
---------- Forwarded Message ----------
Subject: Re: reloading configuration at runtime
Date: Wed, 04 Apr 2001 21:14:34 +0100
From: Robert Burrell Donkin <[EMAIL PROTECTED]>
To: Erik van Zijst <[EMAIL PROTECTED]>
apologies. i posted that last email before i read this one.
i'm interested in design issues in this area so i thought maybe we could
exchange ideas.
(BTW i'm not a log4j commiter just a user)
Erik van Zijst wrote:
> -- Long story, but please read (fundamental architecture extension). --
>
> I've been doing a little thinking myself on the run-time-reload feature.
> If we want to solve it nice clean, I think it's wrong to have
> configureAndWatch() in DOMConfigurator.
> If you want to have this kind of functionality in Configurators, IMHO it
> should at least be in BasicConfigurator, not added in just one of its
> subclasses.
IMHO the configurator archetecture is a little inflexible as it stands at
the moment.
> Next, is the configureAndWatch() strategy of DOMConfigurator. It is very
> limited in the way that it is only useful for polling file stats. If you
> want other kind of refresh-strategies, you could subclass the
> DOMConfigurator and override this method, but it's a crappy way.
i use subclassing but it is a real dirty hack :-(
IMHO
> The logic for deciding when and how to reconfigure, should be separated
> from the Configurator itself.
> JLog does this nicely by using the well-known Observable-Pattern in their
> LogManager.
>
> I think BasicConfigurator should implement Observer. Upon initialization,
> it registers with an Observable which was specified through a
> system-property or config file.
> We (the programmers) would then write our own refresh-observables,
> well-suited for our applications and just tell the BasicConfigurator (or
> whatever subclass) to register itself with that.
> If the Observable name was not specified, the Configurator does nothing.
>
> Initialization of the Observable might be a an interesting issue.
> Especially in J2EE apps, you can't easily guarantee it is instanciated
> before log4j, so it'll have to be done on the fly, at the time the
> Configurator want to register itself.
> A useful way I think is to have the Configurator construct an instance with
> (Observable)(Class.forName().newInstance()) and register. Have no static
> data around and no singletons approach.
hmmm. some interesting ideas but i'm not sure whether this is the most
productive way to go.
log4j is sort of built around singletons. reconfiguring log4j is therefore
pretty easy - you just create a new configurator and call
(for example) the doConfigure method. therefore you don't actually need to
extend the configurator to implement
Observer - you can simply create a new helper class which does.
one interesting feature is that you (should) be able to configure the
configurator from a stream rather than a file.
i suppose that there are two ways to approach this. either have an
event-style design whereby the stream is passed in,
or an observer-style whereby the observer on the client is told when the
configuration needs to be reloaded, and then
it goes and connects to the server and gets hold of the stream to configure
from. i guess that the observer would sidestep
the issues about registration a little better.
> I'm not getting too much feedback from you guys, so I'll walk this path on
> my own (Open Source is great). If anyone's interested after all, drop me a
> note and I'll send patches.
i'm more interested in design (as i said) than classes (since i don't run
EJBs) but i'd be interested to find out how you go on.
- robert
-------------------------------------------------------
--
Dawn, n.:
The time when men of reason go to bed.
-- Ambrose Bierce, "The Devil's Dictionary"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
