logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Discussion regaring configureAndWatch()
Date Fri, 04 Jan 2002 00:19:37 GMT

Although both DOMConfigurator and Propertyonfigurator implement a
configureAndWatch method, is not reason enough to change the Configure
interface. I rather keep the Configure interface trivial. Watching for
config file updates is a useful feature but it is not always

In my opinion, a better approach is to extend
DOMConfigurator/Propertyonfigurator with methods to manage the "watch"
cycle,: to start it, stop it, resume it, change watch frequency
etc. All these methods, except start and resume can be triggered from
within the configuration file itself.

You can tell log4j to use this extended configurator with the
log4j.configuratorClass system property.

Does it make sense? Although not yet implemented, I intend to include
such extended configurators in log4j 1.2. Would you be interested in
implementing these extensions yourself? Regards, Ceki

ps: I have rejected your cross-post to log4j-dev. This is explained in
http://jakarta.apache.org/site/mail.html. The following is
particularly relevant

  Summary: Do not cross post messages.  In other words, pick a mailing
  list and send your messages to that mailing list only. Do not send
  your messages to multiple mailing lists. The reason is that people may
  be subscribed to one list and not to the other. Therefore, some people
  may only see half of the conversation.

At 10:32 04.01.2002 +1100, Scott Farquhar wrote:
>Ceki and others,
>I have some suggestions for log4j, and I am hoping for your feedback. Let me know if you
think that they are worth having.  To let you konw where I am coming from, my interest in
log4j is in use in application servers - most particularly Orion.
>To use log4j in application servers, you mostly wish to do PropertyConfigurator.configureAndWatch(),
or DomConfigurator.configureAndWatch().  Otherwise there is no way for changes to the config
files to be picked up.  As application servers are meant to not be restarted, the need to
re-read config files is critical.
>The current way (that I can see) to start log4j in this way is to have an application
client load the configuration file, and this application client to start automatically.  Whilst
this solution works, it is not the easiest to configure for novice users.
>I started looking at the startup classes and came across the class OptionConverter.java.
 In the process of autoconfiguration (ie finding the properties file according to system property
log4j.configuration - described in section 4.1 http://jakarta.apache.org/log4j/docs/manual/manual.html#N400744),
OptionConverter.selectAndConfigure() calls configurator.doConfigure(url, hierachy).
>My initial idea was that you can change this line to be "configurator.configureAndWatch()".
 That way configuration files loaded by the startup classes would be watched for changes.
 There are two problems with this approach however:
>1.  Interface "Configurator" does not have the method configureAndWatch(), even though
both DomConfigurator and PropertyConfigurator both contain this method.
>2.  "configureAndWatch()" method doesn't take a hierachy, whilst "doConfigure()" does.
>I'll address these separately:
>1.  I cannot see a reason why configureAndWatch() is not in the interface.  Perhaps there
is a reason for this, seeing as configure() isn't either?  Can someone let me know why this
is the case?
>2.  From the code, it seems that the hierachy taken in doConfigure() is always LogManager.getLoggerRepository().
 Can someone explain how the RepositorySelector works?
>Seeing as trying to work _around_ the existing code will be a bit of trouble for me.
>My suggestion is that a new property will be introduced (contained within the property
file), that indicates how often the file is to be reread.  The signature of doConfigure is
changed to return the length of time until the next file read.
>When the watchdog reads the file, it will take the time until the next read, and reset
its internal timer.  This means that config files can also change the time until the next
read.  So during debugging, you can set the config file to be read once a minute, but during
other times, the config file can be read once an hour.
>The changes (from the top of my head):
>- Change method signature of doConfigure() to return a long (millis to next change).
>  - Change doConfigure() of DomConfigurator and PropertyConfigurator to check for update
>  - Decide on new flags / properties for xml & property files.
>- Make a new method doConfigureAndWatch(url, loggerhierachy) which is called by OptionConverter.selectAndConfigure(),
and starts up the watchdog.  (alternatively, if loggerhierachy is not needed, use the existing
>- Add this method to the interface Configurator.
>- Change PropertyWatchDog and DomWatchDog to update their internal delay on each call
>  - ie change implementation of doOnChange()
>Any thoughts?  Is there a way to do this easier (including having the update interval
inside the config files)?  Am I totally off-track?
>I don't see the above breaking any backward compatibility (config files that don't have
the property will continue to be read once).  This functionality is similar to what Ceki mentioned
in this dev post: http://www.mail-archive.com/log4j-dev%40jakarta.apache.org/msg01261.html.
>Let me know any feedback, and sorry for the long email.
>Scott Farquhar :: scott@atlassian.com
>Atlassian :: http://www.atlassian.com
>     Supporting YOUR J2EE World
>To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

Ceki Gülcü - http://qos.ch

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

View raw message