Im working on a patch fix for it now...
The problem is the bug is partly a design flaw..
what good is path? if it doesnt match a) where the file is loaded from.. or b) where its going to be saved to if you use the save() method?
personally i would love to just remove path all together.. it has no use.
----- Original Message ----- From: "Pete Cain" <[EMAIL PROTECTED]>
To: "Jakarta Commons Users List" <[email protected]>
Sent: Tuesday, April 12, 2005 4:21 AM
Subject: Re: [Configuration] ConfigurationFactory resources from classpath/jar.
To answer my own post and stop anyone wasting time on this. Looks to me like a bona fide bug in AbstractFileConfiguration.
AbstractFileConfiguration(String) calls set path which creates a File and breaks the string into basePath and fileName components. Then load() occurs load occurs calling ConfigurationUtils.locate(basePath, fileName). ConfigrationsUtils.locate(String, String) only uses fileName when looking for the resource on the system or context classpaths.
I'll stick this in bugzilla soon.
On Apr 12, 2005 5:58 PM, Pete Cain <[EMAIL PROTECTED]> wrote:
Oliver,
Thanks for that, I read that part but it seems there is a bug somewhere because.
If I do this
PropertiesConfiguration("example/package/configuration/application-version.properties");
I get an exception:
org.apache.commons.configuration.ConfigurationException: Cannot locate
configuration source application-version.properties
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:183)
...
(Its odd that it doesn't report the whole url)
If I do this URL url = ConfigurationUtils.locate(null, "example/package/configuration/application-version.properties");
I get a non null URL refrenece that points to the correct location
If I do this PropertiesConfiguration test = new PropertiesConfiguration(); test.setFileName("example/package/configuration/application-version.properties"); test.load();
The Configurations loads and I can access the values.
Give this behaviour it makes sense that using ConfigurationFactory didn't work as expected.
I have looked thru bugzilla and I haven't found any open bugs that seem to relate to this. I've just started to look thru the source.
But any further suggestions on what could be causing this would be greatly appreciated.
Pete
On Apr 12, 2005 3:58 PM, Oliver Heger <[EMAIL PROTECTED]> wrote: > Pete, > > version 1.1 of commons-configuration already supports loading > configuration files from the classpath. More information about this > subject is available here: > http://jakarta.apache.org/commons/configuration/howto_properties.html > (in the section called "Loading"). > > Oliver > > Pete Cain wrote: > > Hi, > > > > What I'm aiming to do is use commons-configuration to load a bunch of > > configuration data from with in a jar that forms my default > > configuration and then load anything runtime modified configurations > > afterwards. > > > > My problems so far have been with loading configurations as resources > > from the class path. To do this I have customized the digester rules > > use by ConfigurationFactory to give me a <properties-as-resource> tag. > > The digester rule specifies a class that extends > > PropertiesConfiguration and overrides load(String fileName) so that > > the file name is always loaded using getClass().getResource(String). > > I have found this approach to work so far. > > > > What I'd like to know is, am I on the right track with this ? > > Considering I've only just started investigating commons-configuration > > are there any problems I could run into in using the approach ? > > > > Thanks in advance > > > > Pete > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Dipl.-Inform. Oliver Heger > Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren > Klinikum der Philipps-Universit�t Marburg > Baldingerstra�e, > D-35037 Marburg > Tel: +49 6421 28-66679 > mailto:[EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- bludja.blogspot.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
