-- 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.

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.

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.

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.

Erik

On Tuesday 03 April 2001 17:41, you wrote:
> Ceki (and other guru's ;),
>
> Could you shine a light on this?
> I did quite a few tests with log4j already and I want to use it in our EJBs
> in favor of JLog.
>
> Two crucial thing have to be taken care of first though.
>
> First is the reconfiguration thing as described below in the earlier mail.
>
> Second, since the JVM's of our remote clients will be sending us logs over
> RMI, I need the log messages to contain server (IP address) information.
>
> To forward log events over RMI, I wrote the client a RemoteAppender which
> has a reference to an EJB. This EJB exposes one method which takes the
> LoggingEvent. The EJB then passes the events (coming from multiple clients)
> to its Category instance with callAppenders().
>
> Now where do I add server-info? Has to take place at the client (EJB's are
> supposed have no notion of their client's location). It would ultimately
> enable me to filter on servername (or client name, since clients can use
> multiple servers) on the server and log clients to different files.
>
> Another thing is AsyncAppender. My custom RemoteAppender uses RMI and is
> thus very expensive. Access to this Appender should be asynchronous. I can
> configure this in the DOMConfigurator's XML file (already did), but then I
> appear to loose all location information (classname, filename, linenumber).
> What could I do about that?
>
> Thanks in advance,
> Erik
>
> On Monday 02 April 2001 19:04, you wrote:
> > If you instantiate PropertyConfigurator using the following constructor:
> >
> > PropertyConfigurator.configureAndWatch(baseDir+"/conf/server.properties",
> >15 0 00);
> >
> > The first arg is the path to the properties file and the second arg is
> > the time in millis that the properties files will be re-read for runtime
> > changes.
>
> Thanks Bill. I already glanced over the configureAndWatch method.
> Unfortunately it's not exactly what I'm looking for. I need to be able to
> reconfigure the client's logging subsys from the server (using RMI or JMS,
> probably JMS). I cannot edit a config file on the client's machine. Most
> specifically because it's not mine and I have no access to it.
> Clients of ours use our library in their own software on their own
> machines, but this library connects to our EJB servers.
>
> Is there any way I can extend log4j so I can reconfigure it on the fly
> through a method invocation? Should I extend BasicConfigurator for that?
>
> Erik
>
> > Bill Griffith
> >
> >
> >
> >
> > -----Original Message-----
> > From: Erik van Zijst [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 02, 2001 9:21 AM
> > To: [EMAIL PROTECTED]
> > Subject: reloading configuration at runtime
> >
> >
> > Hi all,
> >
> > I've been looking at JLog (IBM) and log4j. I want to use one of these
> > logging
> > toolkits in our software.
> > I have done a number of tests with JLog already and it's quite ok, except
> > perhaps for the closed-source issue.
> >
> > However, log4j looks good as well and I want to give it a fair chance.
> >
> > It will be used in large distributed applications with EJB's and remote
> > clients. One very important requirement is that I must be able to
> > reconfigure
> > the Appenders and Category priorities at runtime.
> >
> > I want to have the clients log to EJB's over leased lines. Normally, I'm
> > not
> >
> > interested in DEBUG level messages since they generate way too much
> > overhead.
> > In an emergency however, I need to be able to change the priorities in
> > the Categories in the running client and start receiving a more verbose
> > stream of
> > log messages on the server.
> >
> > Is it possible to make such flexible configuration changes? With JLog I
> > can.
> >
> > Their LogManager uses an Observer-like pattern.
> >
> > I'm hoping for a quick reply. Please note that I haven't joined the
> > mailinglist, so please CC any replies to my personal address
> > ([EMAIL PROTECTED])
> >
> > Erik

-- 
Syntactic sugar causes cancer of the semicolon.
                -- Epigrams in Programming, ACM SIGPLAN Sept. 1982

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to