commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver.He...@t-online.de (Oliver Heger)
Subject Re: [configuration] Automatic reloading
Date Tue, 16 Dec 2003 19:34:28 GMT
Emmanuel Bourg wrote:

> Oliver Heger wrote:
>
>> Emmanuel,
>>
>> I think after you changed the Configuration interface some classes 
>> won't compile any more because they also implement this interface. 
>> Did you check that?
>
>
> You are right that breaks the HierarchicalConfiguration subclasses, I 
> forgot to add the clear() implementation there. The classes based on 
> BaseConfiguration (xml, jndi & properties) are safe.

Right, I had something in mind that CompositeConfiguration would also be 
affected, but this class already has a clear() method.

>
>
>> I like the idea with reloading properties, but the actual 
>> implementation seems to be a bit too specific for my taste. It is now 
>> possible to reload properties read from file. Some weeks ago the 
>> configuration classes have been extended to support loading from a 
>> URL. Here a reload can't be performed at the moment. And Tim's 
>> suggestion to specify a refresh delay in the configuration definition 
>> XML file is not supported either.
>
>
> For configurations loaded from an URL we might force the reloading 
> after an expiration time, for example 15 minutes. This time could be 
> changed like the refresh delay.
>
>
>> I admit that reloading file based properties will be needed most 
>> times, so this is a good beginning. But maybe we can find a more 
>> generic approach that also supports the other use cases?
>>
>> Perhaps we can introduce something like a Trigger interface (or a 
>> similar concept). Such a trigger can be passed to the Reload 
>> decorator. Then the decorator won't be limited to file change events. 
>> Just an idea...
>
>
> Using an interchangeable strategy is an interesting idea. We could 
> define an abstract class or an interface ReloadingStrategy like this :
>
> public interface ReloadingStrategy {
>     void setConfiguration(Configuration configuration);
>     boolean reloadingRequired();
>     void reloadingPerformed();
> }
>
> I would consider the following implementations :
>
> InvariantReloadingStrategy (no reloading performed)
> TimeoutReloadingStrategy (reload after n seconds)
> FileChangedReloadingStrategy (reload when the file is changed)
> URLChangedReloadingStrategy (for http based URLs only)
> CompositeReloadingStrategy (to mix several strategies)

+1
I am a bit afraid that the actual implementations of 
ConfigurationFactory and CompositeConfiguration may cause trouble when 
implementing this feature. At least when you have a union configuration, 
all properties are collected in a single HierarchicalConfiguration 
object, so the information where they have been loaded from is lost. 
Should always the whole union configuration be loaded when something 
changes? I am not sure how to handle this best...

>
> Emmanuel Bourg
>
>
>
>
>
Oli


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


Mime
View raw message