Henning P. Schmiedehausen wrote:
An idea that popped up was the "versioning locator" mentioned in the reply to Oliver.
This sounds a bit unrealistic for a simple configuration file. But it may make sense in a commons-locator project.
The filename might not be part of the strategy but it is vital to locating the ressource. :-) Does it make sense to have a strategy without a filename / a filename without a strategy (other than defaults)? If no, then we will have to pull a pair of "resource name" / "Locator object") around anyway.
I prefer this rather than merging too many concepts into the same object. This is required only if you have to carry the locator (strategy) all along, but in my opinion once the file is located (URL found) there is no need to keep the locator.
It would reduce the number of C'tors and additional methods from the Configuration implementations.
It might also reduce the duplication of code into classes. Having one set of objects that define the contents of a configuration resource (Properties, XML, whatever) and another set that defines the location of the resource (File, Classpath, JNDI, JDBC) seemed natural to me. Maybe just a brain fart.
It sounds logical but it's not that simple. In [configuration] we have two kinds of configurations:
- the configurations directly connected to a data store, this data store is accessed on every call to getProperty. This is the case of JNDIConfiguration, DatabaseConfiguration, and maybe one day windows and LDAP configurations. These configurations are bound to their data store and separating the definition of the store doesn't make sense.
- the configurations disconnected from the data store, they require a loading and saving mechanism. This is the case of the file based configurations (XML, Properties, and soon INI files). These configurations can be relocated to another place, thus decoupling the configuration from the location makes sense.
I think the notion of "locating a resource" is really specific to the file based configurations, that's why I'm a bit reluctant to try a generalization of the "Locator as a generic definition" concept right now.
Emmanuel Bourg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
