You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <sm...@lfjr.net> on 2004/12/07 18:18:28 UTC
[configuration] File locator
Here is a quick attempt at implementing the Locator strategy discussed
earlier. Feel free to comment :)
Emmanuel Bourg
Re: [configuration] File locator
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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
> null return value.
There may be an issue with the ChainedLocator if we opt for an exception
instead of a null value. If all Locators in the ChainedLocator fail to
locate the file, what exception will be thrown at the end ? We can't
wrap all exceptions in a single exception, so we are losing information
about the causes of the failure.
I think we'd better log the cause of the failure and return null. The
end result for the user if almost the same, the constructor or the load
method will throw a ConfigurationException due to the null URL, and the
cause will be logged.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Henning P. Schmiedehausen wrote:
> Emmanuel Bourg <sm...@lfjr.net> 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.
Not really, but I would prefer a ConfigurationNotFound exception over a
null return value. I think adding another method to the Locator
interface like
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> 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 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.
I'm willing to keep this because we already have it. I'd still like to
see the internal implementation folded onto the Locator so that the
C'tor itself is just a convenience method, not something with real
implementation differences.
>> +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.
>> 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).
Yes, but the digester syntax sucks. :-) Using a non-parameter c'tor
and setters is much easier (BTDT).
>> 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".
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
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by Oliver Heger <he...@med.uni-marburg.de>.
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 several configurations,
> and this is not possible once the file name is bound to the locator, the
> locator must remain "stateless".
>
> Emmanuel Bourg
>
I am not convinced that a Locator must be stateless. In fact my view was
that a Locator serves as a replacement of the URL.
With this stateless strategy approach you will always have problems to
define the correct interface. ATM your locate() method expects a file
name. What if a custom Locator implementation needs more information?
Then the Locator must be initialized separately and cannot be shared
between Configuration objects. Or you use some cryptic encoding in your
string parameter.
So why not keeping all information to locate a configuration source
together in one object? If the name Locator does not fit any more, how
about ConfigurationSource or something?
I still think that a Locator could be useful for saving, too, because
sometimes creating the output stream is part of the locator strategy,
e.g. if a DirectoryLocator needs to create the desired directory
structure if it does not exist yet.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Oliver.Heger@t-online.de (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 following simple method signature:
> URL locate(); // eventuelly throws ConfigurationException?
+1. With throws, please. We will have to deal with exceptions anyway
and it is the job of the application to do so.
>Concrete Locators should have getter and setter methods for the
>properties they need, e.g. the ClasspathLocator a resource name, the
>URLLocator a URL etc. That way a Locator could be created by Digester
>and initialized with a SetPropertiesRule, which comes in handy when used
>with ConfigurationFactory.
Yes. But in this case, I want to have a C'tor which takes the
parameters directly. I could live with
public class FileLocator implements Locator
{
public FileLocator() {...}
public FileLocator(String dir, String file {
setDirectory(dir);
setFile(file);
}
public void setDirectory(String dir) {...}
public void setFile(String file) {...}
public String getDirectory() {...}
public String getFile() {...}
public URL locate() {...}
}
but I want to be able to write a Configuration load still in one
line. I don't care whether it is
Configuration conf = new PropertiesConfiguration(
new FileLocator("/tmp", "foo.properties").locate());
or
Configuration conf = new PropertiesConfiguration(
new FileLocator().locate("/tmp", "foo.properties"));
(though I think that the first one is the better one) but I will not
agree to this as the only way:
Locator loc = new FileLocator();
loc.setDirectory("/tmp");
loc.setFile("foo.properties");
Configuration conf = new PropertiesConfiguration(loc.locate());
commons-configuration is still a helper to real applications. I want
it lean and easy to use. Which means, for normal users, loading a
configuration is a straightforward one-liner. If we give the locator
implementations some sugar to be used with digester or some other
reflection tool, fine, +1. But this still must be an afterthought, not
the main thing.
Currently, you can write a c-c loading with a single line of code. I
want to keep it like this.
>Usage of a Locator would then look like:
>Locator locator = new MyConcreteLocator();
>// init locator as necessary
>Configuration conf = new PropertiesConfiguration(locator);
+1. I can also live with
Configuration conf = new PropertiesConfiguration(locator.locate());
and let the configuration classes only have C'tors with URL.
>in contrast to
>Locator locator = new MyConcreteLocator();
>Configuration conf = new PropertiesConfiguration();
>conf.setBasePath(...);
>conf.setFileName(...);
>conf.load(locator);
Yep. That would suck. That is why I'd like to have
Configuration conf = new PropertiesConfiguration(
new MyConcreteLocator("basepath", "file").locate());
as stated above.
My first choice would still be
Configuration conf = new PropertiesConfiguration(
new MyConcreteLocator("basepath", "file"));
and have the configuration classes take a Locator object in its
C'tor. But Emmanuel does not like this.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by Oliver Heger <Ol...@t-online.de>.
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(); // eventuelly throws ConfigurationException?
Concrete Locators should have getter and setter methods for the
properties they need, e.g. the ClasspathLocator a resource name, the
URLLocator a URL etc. That way a Locator could be created by Digester
and initialized with a SetPropertiesRule, which comes in handy when used
with ConfigurationFactory.
Usage of a Locator would then look like:
Locator locator = new MyConcreteLocator();
// init locator as necessary
Configuration conf = new PropertiesConfiguration(locator);
in contrast to
Locator locator = new MyConcreteLocator();
Configuration conf = new PropertiesConfiguration();
conf.setBasePath(...);
conf.setFileName(...);
conf.load(locator);
Oliver
Emmanuel Bourg wrote:
> Here is a quick attempt at implementing the Locator strategy discussed
> earlier. Feel free to comment :)
>
> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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 constructor and the load method in
AbstractFileConfiguration accepting a Locator
- added setters and default construtors to all Locators
- added static locators in LocatorUtils for the system classpath locator
and the user home locator.
Emmanuel Bourg
Re: [configuration] File locator
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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, "torque.properties"));
There is nothing wrong with this syntax, it's a nice "one liner" to use
a custom locator strategy, but people relying on the default strategy
shouldn't be forced to use it as they would argue that this syntax looks
simpler to them :
Configuration conf = new PropertiesConfiguration("torque.properties");
> I hate adding "convenience constructors". They always come back to
> haunt you.
It's... well... convenient though ;) I will not push for a (String,
Locator) constructor, I can live without it, but I'm not favorable to
remove the (String) constructor.
> Same here. The idea of the locators is to _reduce_ code. Not add new
> methods.
Well, reducing the code was not my goal, I have no problem with the
current size of AbstractFileConfiguration. The goal was just to provide
an alternate strategy to locate the configuration files since the
current design isn't equivalent to the old ClassPropertiesConfiguration.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] File locator
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> 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 load.
>+ *
>+ * @throws ConfigurationException Error while loading the file
>+ * @since 1.1
>+ */
>+ public AbstractFileConfiguration(String fileName, Locator locator) throws ConfigurationException
>+ {
>+ this(locator.locate(null, fileName));
>+ }
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, "torque.properties"));
and ClassPathLocator implemented as
public class ClassPathLocator implements Locator {
public URL locate(...) {...}
}
I hate adding "convenience constructors". They always come back to
haunt you.
>+
>+ /**
>+ * Creates and loads the configuration from the specified file.
>+ *
> * @param file The file to load.
> * @throws ConfigurationException Error while loading the file
> * @since 1.1
>@@ -149,9 +164,21 @@
> */
> public void load(String fileName) throws ConfigurationException
> {
>+ load(fileName, LocatorUtils.getDefaultLocator());
>+ }
Same here. Deprecate all load(...) except load(URL ...) and let the
locator implementations do the translation from file to URL.
>+
>+ /**
>+ * Locate the specified file and load the configuration.
>+ *
>+ * @param fileName the name of the file loaded
>+ *
>+ * @throws ConfigurationException
>+ */
>+ public void load(String fileName, Locator locator) throws ConfigurationException
>+ {
> try
> {
>- URL url = ConfigurationUtils.locate(basePath, fileName);
>+ URL url = locator.locate(basePath, fileName);
> load(url);
> }
> catch (ConfigurationException e)
Same here. The idea of the locators is to _reduce_ code. Not add new
methods.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org