logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Womack" <mwom...@apache.org>
Subject Re: Adding method to o.a.l.spi.Configurator
Date Tue, 07 Dec 2004 08:09:49 GMT
As an update, the only 2 files I need to update to accomadate this api 
change were:


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 

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 


----- Original Message ----- 
From: "Mark Womack" <mwomack@apache.org>
To: "Log4J Developers List" <log4j-dev@logging.apache.org>
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message