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 :: [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]> >> >> > > -- 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]>
