Henning P. Schmiedehausen wrote:
Not really, but I would prefer a ConfigurationNotFound exception over a null return value. I think adding another method to the Locator interface likeEmmanuel Bourg <[EMAIL PROTECTED]> writes:
Henning P. Schmiedehausen wrote:
+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.
Must think more about this. Maybe Oliver has some ideas.
boolean exists();
which could be used to check the existence of the represented file, would be overkill. On the other hand this would make it easier for file based configurations to decide if they should load itself from a file or start with an empty configuration (but with a defined file name for saving).
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).
I fully agree that usage of a Locator should be as easy as possible. So let's have both, constructors and digester friendly getters.
[...]
So let's redefine the meaning of Locator? I'd very much like to capsule the details of a configuration resource into an object. Things like "load from classpath", "use this class loader", "this is the base path", "use this resource name" and so on. I agree, that this _should_ be all URL. However, some of the implementation details are simply not caught here (like the class loader issue).
I understand that you want to reuse the "Locator stategy object" for
multiple invocations. This is not possible with the idea that Oliver
and I seem to share.
So we might simply not want to call it "Locator" but something different. I have a strong feeling that, if we start to drag around a "filename, locator" pair, we will regret this later.
And we will get an Interface signature of URL locate(String filename) e.g. which will be horked if a Locator implementation needs more or less parameters (this custom ClassLoader e.g.). And then you will have to add setters to this custom Locator implementation and have state anyway.
The only thing (IMHO) to get around this is to run "locate()" without parameters and apply state to the Locator object.
Or we give up the idea of an unified Locator interface and just say "plug in any method that returns URL".
Regards Henning
Our ideas are indeed very similar ;-)
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
