logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MCCARTHY Richard <Richard.McCar...@axa-im.com>
Subject RE: reloading configuration at runtime
Date Wed, 04 Apr 2001 10:42:30 GMT

I am also very interested in getting run-time reload features implemented in
Log4J. I feel that the Log4j is very good but is limited in a production
environment if the logging configuration can not be adjusted on the fly.
Your solution sounds a good one and in any case should be available
regardless of the configuration method. 

On a kind of similar kind of track has anyone tried creating a MBean
appender or an appender to interface with JDMK / JMX Agents ? I am going to
try and develop one soon and I am interested if anyone has experience of

Finally :) is there any news on a possible Log4J v1.1 release data ?


-----Original Message-----
From: Erik van Zijst [mailto:erik@marketxs.com]
Sent: 04 April 2001 10:01
To: log4j-user@jakarta.apache.org
Subject: Re: reloading configuration at runtime

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

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

I think BasicConfigurator should implement Observer. Upon initialization, it

registers with an Observable which was specified through a system-property
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
around and no singletons approach.

I'm not getting too much feedback from you guys, so I'll walk this path on
own (Open Source is great). If anyone's interested after all, drop me a note

and I'll send patches.


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
> 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
> 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,
> 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:
> >
> >
> >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:erik@marketxs.com]
> > Sent: Monday, April 02, 2001 9:21 AM
> > To: log4j-user@jakarta.apache.org
> > 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,
> > 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
> > (erik@marketxs.com)
> >
> > Erik

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

To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
This e-mail is confidential and intended only for the
addressee(s) shown.  If you are not an intended recipient, please be advised
that any use, dissemination, forwarding or copying of this e-mail is
strictly prohibited.  Internet e-mails are not necessarily secure and the
AXA Group does not accept responsibility for changes made to this message
after it was sent. Please note that AXA Investment Managers may monitor
incoming and outgoing electronic mail messages. Should you receive this
transmission in error, notify the sender immediately.  Thank you

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

View raw message