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...
Oli
Emmanuel Bourg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
