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 12:28:24 UTC
Re: [CONFIGURATION] ClassPropertiesConfiguration
Henning P. Schmiedehausen wrote:
> with this class gone from the 1.0 release; how am I supposed to load a
> file from the classpath? just use new PropertiesConfiguration(file)
> and hope that ConfigurationUtils.locate() doesn't match another file
> by accident?
Hi, yes that's the purpose of the locate() method. Alternatively you can
provide your own URL if you want to be sure the right file is selected.
Regarding the locate() method I hesitated to implement a more generic
design but I didn't want to start with an over designed solution. The
idea was to introduce a Locator interface, a Locator implements a
strategy for finding a resource:
public interface Locator {
URL locate(String basepath, String filename);
}
Then we would have a ClassPathLocator, a HomeDirectoryLocator, a
ChainedLocator, etc... A default locator would be provided but could be
overridden, thus you could implement your customized strategy.
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] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>This is just a matter of good documentation ;) Shortcuts are just
>allowed as replacements of the fully qualified class names, the range of
>values accepted is not locked to the set of shortcuts.
Ok, that seems reasonable.
>> If you look at the Torque OM templates where the type of ID generator
>> is determined ("native", "sequence", "idbroker" and so on), you will
>> see, that you end up with a huge mess.
>>
>> Where does Hibernate allow short-cuts / human readable names? The only
>> place that I can remember is the fact that you can omit the packages
>> for the class <-> table mappings if you supply a default package with
>> the mapping itself. That would be no problem (then there would just be
>> a typo in your example because you've written "classpath" instead of
>> "ClassPathLocator" (the o.a.c.c.locator could be the default package).
>Like Torque I guess, Hibernate supports shortcuts for id generators :
>http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-id-generator
Ah, I didn't know that.
>And for property types:
>http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-property
:-)
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] ClassPropertiesConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> You lock yourself into a very small number of possible field
> values. And you confuse your users (IMHO) by allowing two types of
> parameters (readable names and class names) in a single attribute.
This is just a matter of good documentation ;) Shortcuts are just
allowed as replacements of the fully qualified class names, the range of
values accepted is not locked to the set of shortcuts.
> If you look at the Torque OM templates where the type of ID generator
> is determined ("native", "sequence", "idbroker" and so on), you will
> see, that you end up with a huge mess.
>
> Where does Hibernate allow short-cuts / human readable names? The only
> place that I can remember is the fact that you can omit the packages
> for the class <-> table mappings if you supply a default package with
> the mapping itself. That would be no problem (then there would just be
> a typo in your example because you've written "classpath" instead of
> "ClassPathLocator" (the o.a.c.c.locator could be the default package).
Like Torque I guess, Hibernate supports shortcuts for id generators :
http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-id-generator
And for property types:
http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-property
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] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
>> Nah! We went this road in torque with the id generators and along lies
>> madness! Please don't try to "sweeten" the locator names by
>> introducing human readable names into the XML syntax.
>What's wrong with that ? From a user point of view it's easier to have
>short names than fully qualified class names. Hibernate uses this
>approach in its mapping file, I find this quite nice. Of course it's
>still possible to use the class name instead.
You lock yourself into a very small number of possible field
values. And you confuse your users (IMHO) by allowing two types of
parameters (readable names and class names) in a single attribute.
If you look at the Torque OM templates where the type of ID generator
is determined ("native", "sequence", "idbroker" and so on), you will
see, that you end up with a huge mess.
Where does Hibernate allow short-cuts / human readable names? The only
place that I can remember is the fact that you can omit the packages
for the class <-> table mappings if you supply a default package with
the mapping itself. That would be no problem (then there would just be
a typo in your example because you've written "classpath" instead of
"ClassPathLocator" (the o.a.c.c.locator could be the default package).
>> I'd very much prefer
>>
>> <properties locatorClass="org.apache.commons.configuration.locator.ClassPathLocator">
>> <param name="fileName" value="config.properties" />
>> </properties>
>>
>> over that. Using attributes locks us into a defined set of fields by the DTD.
>Err... but we don't have any DTD for the configuration descriptor ;)
We might get one some day. :-)
Hibernate got that right, BTW:
<ResourceParams name="jdbc/quickstart">
<parameter>
<name>factory</name>
<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
</parameter>
<!-- DBCP database connection settings -->
<parameter>
<name>url</name>
<value>jdbc:postgresql://localhost/quickstart</value>
</parameter>
</ResourceParams>
instead of
<ResourceParams name="jdbc/quickstart" factory="org.apache.commons.dbcp.BasicDataSourceFactory" url="jdbc:postgresql://localhost/quickstart" />
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] ClassPropertiesConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> Nah! We went this road in torque with the id generators and along lies
> madness! Please don't try to "sweeten" the locator names by
> introducing human readable names into the XML syntax.
What's wrong with that ? From a user point of view it's easier to have
short names than fully qualified class names. Hibernate uses this
approach in its mapping file, I find this quite nice. Of course it's
still possible to use the class name instead.
> I'd very much prefer
>
> <properties locatorClass="org.apache.commons.configuration.locator.ClassPathLocator">
> <param name="fileName" value="config.properties" />
> </properties>
>
> over that. Using attributes locks us into a defined set of fields by the DTD.
Err... but we don't have any DTD for the configuration descriptor ;)
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] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>I would not add the locator alias in front of the resource name, that
>would look like an URL, but I like the idea. We could just add a locator
>attribute :
><properties locator="classpath" fileName="config.properties"/>
Nah! We went this road in torque with the id generators and along lies
madness! Please don't try to "sweeten" the locator names by
introducing human readable names into the XML syntax.
I'd very much prefer
<properties locatorClass="org.apache.commons.configuration.locator.ClassPathLocator">
<param name="fileName" value="config.properties" />
</properties>
over that. Using attributes locks us into a defined set of fields by the DTD.
Regads
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] ClassPropertiesConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Oliver Heger wrote:
> Locators would also be very useful for ConfigurationFactory to be used
> in the definition files. This would imply an extensible means of
> representing Locators as text, so you could write something like
>
> <!-- classpath locator -->
> <properties locator="classpath:/myproperties"/>
> <!-- Custom locator -->
> <xml locator="my.package.MyLocator" params="..."/>
>
> Just a quick shot, this needs to be further elaborated.
I would not add the locator alias in front of the resource name, that
would look like an URL, but I like the idea. We could just add a locator
attribute :
<properties locator="classpath" fileName="config.properties"/>
> Would it make sense to use Locators also for saving configurations? For
> this purpose a locate() method would be needed that returns an
> OutputStream.
I don't think so, the location mechanism is specific to the loading of
the file, saving is a different beast, once the file has been loaded
it's expected to be saved at the same place. That why I didn't want to
remove the internal URL in AbstractFileConfiguration.
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] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Oliver Heger <he...@med.uni-marburg.de> writes:
>Just a quick shot, this needs to be further elaborated.
>Would it make sense to use Locators also for saving configurations? For
>this purpose a locate() method would be needed that returns an OutputStream.
maybe locateLoad() and locateSave() and simple implementations can just do
public URL locateLoad(...xxx...) { return locate(...xxx...) };
public URL locateSave(...xxx...) { return locate(...xxx...) };
private URL locate(...xxx...) { ... }
(which would e.g. allow to write a versioning locator. Every write creates a new revision entry in
something like subversion...)
Regards
Henning
>Oliver
>Emmanuel Bourg wrote:
>> Henning P. Schmiedehausen wrote:
>>
>>> I don't think, this is overengineered. Are you sure about URL locate?
>>> I'd probably go for InputStream locate().
>>
>>
>> Is that for classloaders that do no support getRessource ? We really
>> need to know where the file is located in order to reload it efficiently.
>>
>>> Hm. I probably would like this solution better than the current (which
>>> reminds me of the way that commons-logging tries to find its log
>>> APIs). We could use current as the default and make the others
>>> pluggable. (and add a few C'tors which accept a Locator object)
>>
>>
>> We could either keep the current constructors and use the Locator
>> directly :
>>
>> new PropertiesConfiguration(locator.locate("config.properties));
>>
>> or add one constructor :
>>
>> new PropertiesConfiguration("config.properties", locator);
>>
>> in this case we'll also need another load method :
>>
>> config.load("config.properties", locator);
>>
>>
>> I think I prefer starting with the first solution.
>>
>> Emmanuel Bourg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>--
>Dipl.-Inform. Oliver Heger
>Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
>Klinikum der Philipps-Universit�t Marburg
>Baldingerstra�e,
>D-35037 Marburg
>Tel: +49 6421 28-66923
>mailto:oliver.heger@med.uni-marburg.de
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
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] ClassPropertiesConfiguration
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Locators would also be very useful for ConfigurationFactory to be used
in the definition files. This would imply an extensible means of
representing Locators as text, so you could write something like
<!-- classpath locator -->
<properties locator="classpath:/myproperties"/>
<!-- Custom locator -->
<xml locator="my.package.MyLocator" params="..."/>
Just a quick shot, this needs to be further elaborated.
Would it make sense to use Locators also for saving configurations? For
this purpose a locate() method would be needed that returns an OutputStream.
Oliver
Emmanuel Bourg wrote:
> Henning P. Schmiedehausen wrote:
>
>> I don't think, this is overengineered. Are you sure about URL locate?
>> I'd probably go for InputStream locate().
>
>
> Is that for classloaders that do no support getRessource ? We really
> need to know where the file is located in order to reload it efficiently.
>
>> Hm. I probably would like this solution better than the current (which
>> reminds me of the way that commons-logging tries to find its log
>> APIs). We could use current as the default and make the others
>> pluggable. (and add a few C'tors which accept a Locator object)
>
>
> We could either keep the current constructors and use the Locator
> directly :
>
> new PropertiesConfiguration(locator.locate("config.properties));
>
> or add one constructor :
>
> new PropertiesConfiguration("config.properties", locator);
>
> in this case we'll also need another load method :
>
> config.load("config.properties", locator);
>
>
> I think I prefer starting with the first solution.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Dipl.-Inform. Oliver Heger
Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
Klinikum der Philipps-Universität Marburg
Baldingerstraße,
D-35037 Marburg
Tel: +49 6421 28-66923
mailto:oliver.heger@med.uni-marburg.de
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CONFIGURATION] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>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.
I was thinking more of a custom locator implementation. Not something to be
put into the commons realm.
>> 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.
Ok. I see your point.
[...]
>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.
Ok, so we should make clear, that Locator is intended as "file name ->
URL" translation class. However, for me, the file name is still a
parameter of the Locator, not of the configuration.
If we change this, then we should short-cut
PropertiesConfiguration(String fileName)
and
PropertiesConfiguration(File file)
with
public PropertiesConfiguration(String fileName) {
this(FileLocator.locate(fileName));
}
public PropertiesConfiguration(File file) {
this(FileLocator.locate(file.getName()));
}
and deprecate these C'tors, shouldn't we?
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] ClassPropertiesConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CONFIGURATION] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
>>>new PropertiesConfiguration(locator.locate("config.properties));
>>
>> I don't like that much. Once the locator has run, it has run. Passing
>> the locator object allows the implementor to catch all the calls to
>> locate() and maybe react differently.
>I'm not sure to see the need, do you have a real use case in mind ?
An idea that popped up was the "versioning locator" mentioned in the
reply to Oliver.
>> How about wrapping the name of the configuration file / the
>> configuration parameters into the locator object:
>>
>> config = new PropertiesConfiguration (new FileLocator("config.properties"));
>> config = new PropertiesConfiguration (new ClassPathLocator("config.properties"));
>>
>> config.load(new FileLocator("config.properties"));
>Hmm no because a locator is a strategy to find a resource, it doesn't
>define a resource, this is the role of the URL.
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.
>> This would simplify the method signatures. We might even be able to
>> decouple things like JDBC and JNDI:
>>
>> config = new PropertiesConfiguration(new JDBCLocator(... jdbc params...));
>Is this really simpler than instanciating DatabaseConfiguration and
>JNDIConfiguration ? :)
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.
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] ClassPropertiesConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> Yep. However, we could simply say, that for using this, you have to
> have an URL. One can always fake up a Locator that loads the file from
> the input stream, saves it to a temp file and returns this URL.
Yes that's a solution, alternatively the user can still call the
load(InputStream) method.
>>new PropertiesConfiguration(locator.locate("config.properties));
>
> I don't like that much. Once the locator has run, it has run. Passing
> the locator object allows the implementor to catch all the calls to
> locate() and maybe react differently.
I'm not sure to see the need, do you have a real use case in mind ?
> How about wrapping the name of the configuration file / the
> configuration parameters into the locator object:
>
> config = new PropertiesConfiguration (new FileLocator("config.properties"));
> config = new PropertiesConfiguration (new ClassPathLocator("config.properties"));
>
> config.load(new FileLocator("config.properties"));
Hmm no because a locator is a strategy to find a resource, it doesn't
define a resource, this is the role of the URL.
> This would simplify the method signatures. We might even be able to
> decouple things like JDBC and JNDI:
>
> config = new PropertiesConfiguration(new JDBCLocator(... jdbc params...));
Is this really simpler than instanciating DatabaseConfiguration and
JNDIConfiguration ? :)
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] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
>> I don't think, this is overengineered. Are you sure about URL locate?
>> I'd probably go for InputStream locate().
>Is that for classloaders that do no support getRessource ? We really
>need to know where the file is located in order to reload it efficiently.
Yep. However, we could simply say, that for using this, you have to
have an URL. One can always fake up a Locator that loads the file from
the input stream, saves it to a temp file and returns this URL.
>> Hm. I probably would like this solution better than the current (which
>> reminds me of the way that commons-logging tries to find its log
>> APIs). We could use current as the default and make the others
>> pluggable. (and add a few C'tors which accept a Locator object)
>We could either keep the current constructors and use the Locator directly :
>new PropertiesConfiguration(locator.locate("config.properties));
I don't like that much. Once the locator has run, it has run. Passing
the locator object allows the implementor to catch all the calls to
locate() and maybe react differently.
>or add one constructor :
>new PropertiesConfiguration("config.properties", locator);
>in this case we'll also need another load method :
>config.load("config.properties", locator);
How about wrapping the name of the configuration file / the
configuration parameters into the locator object:
config = new PropertiesConfiguration (new FileLocator("config.properties"));
config = new PropertiesConfiguration (new ClassPathLocator("config.properties"));
config.load(new FileLocator("config.properties"));
This would simplify the method signatures. We might even be able to
decouple things like JDBC and JNDI:
config = new PropertiesConfiguration(new JDBCLocator(... jdbc params...));
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] ClassPropertiesConfiguration
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> I don't think, this is overengineered. Are you sure about URL locate?
> I'd probably go for InputStream locate().
Is that for classloaders that do no support getRessource ? We really
need to know where the file is located in order to reload it efficiently.
> Hm. I probably would like this solution better than the current (which
> reminds me of the way that commons-logging tries to find its log
> APIs). We could use current as the default and make the others
> pluggable. (and add a few C'tors which accept a Locator object)
We could either keep the current constructors and use the Locator directly :
new PropertiesConfiguration(locator.locate("config.properties));
or add one constructor :
new PropertiesConfiguration("config.properties", locator);
in this case we'll also need another load method :
config.load("config.properties", locator);
I think I prefer starting with the first solution.
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] ClassPropertiesConfiguration
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
>> with this class gone from the 1.0 release; how am I supposed to load a
>> file from the classpath? just use new PropertiesConfiguration(file)
>> and hope that ConfigurationUtils.locate() doesn't match another file
>> by accident?
>Hi, yes that's the purpose of the locate() method. Alternatively you can
>provide your own URL if you want to be sure the right file is selected.
>Regarding the locate() method I hesitated to implement a more generic
>design but I didn't want to start with an over designed solution. The
>idea was to introduce a Locator interface, a Locator implements a
>strategy for finding a resource:
>public interface Locator {
> URL locate(String basepath, String filename);
>}
I don't think, this is overengineered. Are you sure about URL locate?
I'd probably go for InputStream locate().
>Then we would have a ClassPathLocator, a HomeDirectoryLocator, a
>ChainedLocator, etc... A default locator would be provided but could be
>overridden, thus you could implement your customized strategy.
Hm. I probably would like this solution better than the current (which
reminds me of the way that commons-logging tries to find its log
APIs). We could use current as the default and make the others
pluggable. (and add a few C'tors which accept a Locator object)
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