Oliver Heger wrote:
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.
Not really, but I would prefer a ConfigurationNotFound exception over a
Henning P. Schmiedehausen wrote:
Emmanuel 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
implemen
Emmanuel Bourg wrote:
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 sever
Emmanuel Bourg <[EMAIL PROTECTED]> writes:
>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
I modified the first implementation :
- the basepath parameter has been removed from the "locate" method
signature. The signature is now locator(String name):URL
- URLLocator now has a basepath property
- added a basepath parameter on the getDefaultLocator method in LocatorUtils
- removed the con
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 figure
Henning P. Schmiedehausen wrote:
I don't like this. Yet another C'tor. We shouldn't add C'tors, we
should deprecate AbstractFileConfiguration(String) and force people to
use the locators directly. What is wrong with
Configuration conf = new PropertiesConfiguration(new ClassPathLocator().locate(null
[EMAIL PROTECTED] (Oliver Heger) writes:
>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 !
>concrete Locator has to deal with, and the information needed by a
>Locator may vary. So I suggest the follow
Emmanuel Bourg <[EMAIL PROTECTED]> writes:
>Here is a quick attempt at implementing the Locator strategy discussed
>earlier. Feel free to comment :)
[...]
> /**
> * Creates and loads the configuration from the specified file.
> *
>+ * @param fileName The name of the file to loa
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
concrete Locator has to deal with, and the information needed by a
Locator may vary. So I suggest the following simple method signature:
URL locate(); // ev
Here is a quick attempt at implementing the Locator strategy discussed
earlier. Feel free to comment :)
Emmanuel Bourg
Index: src/java/org/apache/commons/configuration/AbstractFileConfiguration.java
===
RCS file:
/home/cvs/jakarta-c
11 matches
Mail list logo
