Ralph Goers wrote: > > On Aug 24, 2009, at 11:34 AM, Oliver Heger wrote: > >> Currently there are many ways to specify the location for a file- >> based configuration: as a URL, as a File, a file name, a base path... >> It was a major effort to keep the several get and set methods for >> these properties in sync. >> >> With the new implementation based on the FileSystem class (which I >> have not yet studied in detail I have to confess) I wonder whether >> there is a better approach for the configuration2 branch. Would it be >> possible to simplify the interface for file-based configurations, >> e.g. by introducing a generic Locator class? >> >> Another remark about the DefaultFileSystem class: Currently the >> functionality for locating files seems to be smeared between >> DefaultFileSystem and ConfigurationUtils. Would it be better to >> refactor it into a central location? >> > > I will admit that the FileSystem class isn't all that pretty. My main > goal was to be able to hook in Commons VFS. So all I did was refactor > out all the places that were directly tieing into either a File object > or Http and created the FileSystem and DefaultFileSystem to handle > that. VFSFileSystem extends DefaultFileSystem and overrides a lot of > the methods to interact with Commons VFS. This obviously isn't the best > interface to use since it was designed to maintain compatibility, not > as an optimal solution. > > Frankly, Since Commons VFS can or could do anything you would want in > the way of abstracting file handling it would make the most sense to me > to just leverage its capabilities and use it as the abstraction layer > since that what it was designed to do. I would remove the direct > support for File objects and Http from Commons Configuration entirely. > > And yes, there is a bit of overlap between ConfigurationUtils and > DefaultFileSystem. Again, to preserve compatibility I did not remove > methods from ConfigurationUtils. > I am not sure whether we should really add a hard dependency to Commons VFS. For many standard applications that just need to read some configuration files this seems to be overkill. So in principle I like the approach with the FileSystem abstraction and the simple default implementation that can be replaced by a fully-featured VFS-based implementation.
Anyway, if we do not have to take backwards compatibility into account in the configuration2 branch, how could an interface for file-based configurations look like? Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
