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.
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)
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Signature
