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 01:23:15 GMT

It moved to /build.xml. For CVS readonly access see http://jakarta.apache.org/site/cvsindex.html
Module name is "jakarta-log4j". 

How about WatchingDOMConfigurator or ScanningDOMConfiguratoror or DOMConfiguratorII or DOMConfiguratorX
or ....  Your naming choice is as good as mine. Regards, Ceki

At 11:43 04.01.2002 +1100, you wrote:
>I hate replying to my own posts - but where is build.xml ?  I can find it in version 1.1.3
(in dir /build/), but there is no /build/build.xml in 1.2 alpha5?
>
>Also - is there read cvs access anywhere?  Or is alpha5 the most cutting-edge it gets?
>
>Cheers,
>Scott
>
>Scott Farquhar wrote:
>
>>Ceki,
>>Sorry about the cross-post, I meant to post to the dev list, but my mail  reader auto-completed
the wrong address.
>>I would be interested in extending DomConfigurator.  Any ideas on what it should be
called?  Anyone also interested in this feature that would like to input their ideas?
>>Cheers,
>>Scott
>>Ceki Gülcü wrote:
>>
>>>cott,
>>>
>>>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
>>>necessary.
>>>
>>>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 period
>>>>- 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 methods.)
>>>>- 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.
>>>>
>>>>Cheers,
>>>>Scott
>>>>-- 
>>>>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>
>>>
>
>
>-- 
>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>


Mime
View raw message