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]
