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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
