logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Kristensen <akristen...@dynamicsoft.com>
Subject Re: reloading configuration at runtime
Date Wed, 18 Apr 2001 21:18:42 GMT

Paul Glezen wrote:
> Hi Erik,
> Sorry to jump in a little late.  I monitor this list on my home PC but I
> travel during the week.
> Erik van Zijst wrote:
> >
> > First is the reconfiguration thing as described below in the earlier mail.
> >
> That's a tough one.  Log4j is certainly configurable at runtime.  There
> are two notions of runtime configuration.  What others call runtime
> log4j would call initialization time (via property files).  The
> configuration can also be changed later in runtime programatically.  As
> you're aware, it can only be done locally (within the same JVM).
> I'm not familiar with having an EJB server call an EJB client in order
> to change client attributes (whether it be logging or otherwise).  I am
> currently working on a reasonably sized CORBA (insurance claim
> registration call center) that has recently gone in production.  To
> change client properties, we use the old-fashon approach of sending out
> modified property files to the client machine and restarting.  Most
> enterprises are very good at distributed files out to client machines in
> an automated manner.  If a particular Customer Service Rep (CSR) called
> in saying her machine was acting funny, we could either send her a
> modified property file with configuration changes or have someone at the
> CSR location (in a different timezone than some of the servers) do it
> directly.
> Remote configuration is something I'm very interested in and continue to
> regularly think about.  One direction with potential is providing JMX
> implementations of certain log4j elements.  But other than Sun's
> reference implemenation and Tivoli's TMX (from IBM's alphaworks site),
> we're somewhat short of an abundance of JMX agents to choose from.

This is consistent with Java management and our recent move to a
JavaBeans based style of configuration. I'm interested in a different
type of remote configuration also which is to have a very simple
embedded HTTP server running in a JVM and be able to retrieve that VMs
log4j configuration by doing an HTTP GET and reconfiguring it by doing a
POST with the body being the Java properties or XML configuration file.
I've got such a mechanism working now and may check it in when I get
time to clean it up.

Anders Kristensen

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

View raw message