Emmanuel Bourg wrote:

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.

Actually, you could still support that. Just have FileConfiguration have a File[] getFiles() method (or Iterator getFileIterator() ) method instead of a getFile() method. Then you could do this:


public class BasePropertiesConfiguration extends ... implements FileConfiguration
{
protected File fPropertiesFile;
protected List fChildList = new ArrayList( 2 );


...

   public File[] getFiles()
   {
       List allFiles = new ArrayList();
       allFiles.add( fPropertiesFile );
       for ( Iterator iter = fChildList.iterator(); iter.hasNext(); )
       {
           FileConfiguration child = (FileConfiguration) iter.next();
           allFiles.addAll( Arrays.asList( child.getFiles() ) );
       }
       File[] fileArray = new File[allFiles.size()];
       return (File[]) allFiles.toArray( fileArray );
   }

   ...
}

I've not actually looked at the BasePropertiesConfiguration code, but that's a rough approximation of what you could do. Then ReloadableConfiguration could check all the files returned by getFiles() and reload the base configuration (which would reload the children) if any of the files had changed. Or you could do something fancier, traversing to the individual child Configurations using some sort of CompositeConfiguration and only reloading the individual Configuration that changed; but that would probably be more trouble than it would be worth.

- Eric



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to