o.a.l.PropertyConfigurator o.a.l.varia.ReloadingPropertyConfigurator
I'm not even sure what ReloadingPropertyConfigurator is since it does not have any implementation. DOMConfigurator and the JoranConfigurator already had a version of doConfigure(InputStream, LoggerRepository), so the api change did not require any changes there.
But again, if developers have created their own Configurator classes that do not implement the new method, then they will need to add it in order to use v1.3.
If no strong objections, I will add the changes in tomorrow evening. I should also have a first version of the FileWatchdog ready tomorrow as well. Then we can start testing it to make sure it allows web apps to properly shutdown.
-Mark
----- Original Message ----- From: "Mark Womack" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 06, 2004 10:24 PM
Subject: Adding method to o.a.l.spi.Configurator
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
--------------------------------------------------------------------- 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]
