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 :: [EMAIL PROTECTED] > >Atlassian :: http://www.atlassian.com > Supporting YOUR J2EE World > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
