;-) thank you for putting my name in the author field of ReloadingStrategy, but I do not deserve this honour. This is all your design.
I have one remark and this is not specific to your code, but applies to whole configuration: Our exception handling is very inconsistent in some points. For instance, in the new PersistentConfiguration interface the save() method throws an IOException and the load() method throws an Exception. I know, this is because the underlying methods you want to call have these throws clauses. So I would suggest to make this more consistent.
There are some methods that have a throws Exception clause, which is quite ugly in my opinion. Well, some of them can indeed throw a bunch of different exception types. What could we do to improve this? How about introducing a ConfigurationException class, which can have a nested exception?
What do others think about this? This is a kind of cleanup, which maybe should be done before the first release. Later it could be more problematic because of compatibility issues.
Oli
Emmanuel Bourg schrieb:
I have implemented the reloading strategy suggested by Oliver. I introduced a PersistentConfiguration interface defining the load() and save() methods, the ReloadableConfiguration decorator only accepts instances of PersistenConfiguration. Also I fixed the missing clear() method in the HierarchicalConfiguration class and moved the reloading stuff in a specific sub package.
I haven't implemented all the strategies mentioned in my previous mail yet. I think we might make the URLChangedReloadingStrategy to work on configurations embedded in a jar or zip file as well, this should be easy to implement with the JarFile/JarEntry obtained from the URL through a JarURLConnection.
Emmanuel Bourg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
