I like the idea of a decorator, I'm implementing it currently. I see one issue though, I was considering a refactoring of the include logic in BasePropertiesConfiguration to use a tree of configurations, i.e. if the property can't be found in the parent configuration, it would look up in the children configurations.

With a decorator pattern the included configurations can't be reloaded automatically unless the BasePropertiesConfiguration wraps them in a ReloadableConfiguration. In this case it wouldn't be possible to manage their reloading properties (enabling/disabling, refresh delay). If the PropertiesConfiguration was reloadable, it could propagate its reloading properties to its children.

Emmanuel Bourg


Eric Galluzzo wrote:

Alternatively, it might be nice to introduce a FileConfiguration interface that just has a java.io.File getFile() method. Both DOM4JConfiguration and PropertiesConfiguration would implement this. Then one could repackage your existing ReloadablePropertiesConfiguration as a ReloadableConfiguration that implements Configuration but delegates to another FileConfiguration and checks the file every so often. Thus:

Configuration config = new ReloadableConfiguration(
   new DOM4JConfiguration( myXMLFile ) );

or

Configuration config = new ReloadableConfiguration(
   new PropertiesConfiguration( myPropFile ) );

This is a Decorator design reminiscent of FilteredOutputStream and FilteredInputStream.

- Eric

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to