Emmanuel,
;-) thank you for putting my name in the author field of ReloadingStrategy, but I do not deserve this honour. This is all your design.
That was your idea ;)
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.
Indeed, I started with the load() and save() methods throwing an IOException, then I changed to an Exception on load() to be compatible with the DOM4JConfiguration.load() method throwing a DOM4JException.
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?
I agree, that's a common practice. If a persistent configuration was stored into a database we would get a SQLException on load() & save(), so we need a generic exception abstracting the implementation exceptions. A ConfigurationException is a better choice than a simple 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.
Is there a 1.0 release planned soon after the promotion of [configuration] to Commons Proper ?
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Signature