I don't get your comment. Maybe I did not make myself clear. Watchdogs will not be deriving from the Configurator interface. They are clients of the Configurator interface. You specify the Configurator class to use, the Watchdog creates and instance of that Configurator and then calls the doConfigure method on that instance to reconfigure the log4j environment.
My point is that for some configuration sources, only having a version of doConfigurator that takes a URL is not sufficient. My example was with Socket, but another example might be JMS. Does that make sense? -Mark -----Original Message----- From: Ceki G�lc� [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:50 AM To: Log4J Developers List Subject: Re: Adding method to o.a.l.spi.Configurator Mark, Instead of adding watchdog functionality by adding another Configurator derived from PropertyConfigurator or JoranConfigurator, you should consider an architectures where watchdogs are independent (class derivation wise) of the Configurator interface. For example, a configuration file could look like this: <log4j:configuration> <watchdog class="org.apache.log4j.whatever.Watchdog"> <!-- "this" means the current resource. Joran will make its URL available to the WatchdogAction dealing with this directive. --> <param name="url" value="this"/> <param name="checkFrequency" value="60s"/> <param name="resetOnChange" value="true"/> </watchdog> // other directives follow <appender name="..."> .... </log4j:configuration> Oh, I am not in favor of modifying the Configurator interface. At 07:24 AM 12/7/2004, Mark Womack wrote: >We have discussed this before, many moons ago. In order to better support >the various types of Watchdogs I want to implement in v1.3, I want to add >the following method to the Configurator interface: > > /** > Use an InputStream as a source for configuration and set up log4j > accordingly. > > The configuration is done relative to the <code>hierarchy</code> > parameter. > > @param stream The input stream to use for configuration data. > @param repository The repository to operate upon. > */ > void doConfigure(InputStream stream, LoggerRepository repository); > >Doing this in v1.3 will mean that v1.2.X implementations of Configurator >will need to implement this new method to be compatible with the v1.3 >environment. This will be a breaking change. I will update the >Configurator implementations in the log4j framework, but if developers >have implemented their own Configurator classes, they will need to fix them. > >Implemention is trivial because when implementing the version for URL, one >generally uses URL.openStream() to load the configuration data. I have >not looked at the Joran configurator, but I assume it is using InputStream >or InputSource to access the configuration data at some point. > >By updating Configurator to not have such a bias to URL-only sources, it >will make it easier to implement watchdogs for other types of sources, >such as Sockets. In the Socket case, there is no URL that can be used to >describe it (AFAIK), but an InputStream can be easily obtained and used as >the source for configuration data. > >Since watchdogs are designed to watch specific kinds of sources, >independent of specific Configurator types, having both a URL and >InputStream version of doConfigure will make it possible for watchdogs to >call the appropriate version as required by the kind of source being >watched (ie URL vs Socket). > >I will be making this change shortly unless there are strident objections. > >-Mark -- Ceki G�lc� The complete log4j manual: http://qos.ch/log4j/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
