Henning P. Schmiedehausen wrote:
If we have Loccators, IMO there is no need to keep the base path and file name stuff in file based configurations. These are things a
+1 !
-1 to remove the file name from the method signature, I'll explain later. +1 to remove the base path, but I haven't figured how to do it yet ;) Using the base path as a locator parameter, just like the classloader for the ClasspathLocator is most likely the solution. But it doesn't fit well with the LocatorUtils.getDefaultLocator() method.
+1. With throws, please. We will have to deal with exceptions anyway and it is the job of the application to do so.
I'm not sure about that, I had no need for exceptions in my implementation, when I dealt with exception it meant the file could not be located, and the locator returned a null URL.
An alternative is to throw a ConfigurationNotFound exception extending ConfigurationException instead of returning null, but I'm not fond of this.
Yes. But in this case, I want to have a C'tor which takes the parameters directly.
I agree for the same reasons, it's nice to be "digester friendly" with setters, but that doesn't prevent us from adding a non empty constructor. It may even be possible to make digester use the constructor directly with a specific rule (if it doesn't already exist).
and have the configuration classes take a Locator object in its C'tor. But Emmanuel does not like this.
Indeed, as I explained, once you write
new MyConcreteLocator("basepath", "file")The locator is no longer a strategy to locate the file, it becomes an object defining the location of the file (i.e it could replace the URL). The same strategy should also be reusable for several configurations, and this is not possible once the file name is bound to the locator, the locator must remain "stateless".
Emmanuel Bourg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
