commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35316] - [configuration] ConfigurationFactory not working as expected with include path resolution
Date Sun, 21 Aug 2005 00:53:12 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35316>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35316





------- Additional Comments From hoju@visi.com  2005-08-21 02:53 -------
Seems odd to me that one expect that file-based resources referenced from within
a config.xml file would need to be specified with a full relative path from
which the config.xml was originally loaded.  But that seems to be what you say
your unit tests expect.  That's very weird to me.  I wouldn't expect many people
to have made that assumption.  So, you are saying that you load up a config.xml
file as such...

ConfigurationFactory factory = new ConfigurationFactory("etc/props/config.xml");

And then the config.xml would look something like this?...

<configuration>
  <properties fileName="etc/props/usergui.properties"/>
</configuration>

First, I can't fathom anyone else making this assumption.  Second, it makes the
config.xml file location dependent.  Put config.xml in any other path such as
"etc/config" and all of a sudden, usergui.properties can't be found anymore
without changing the file to look like...

<configuration>
  <properties fileName="etc/config/usergui.properties"/>
</configuration>

Files referenced with a relative path within config.xml should be relative to
wherever config.xml happens to be.  That's clearly correct behavior and existing
commons-configuration behavior is clearly incorrect.  I don't think there is
much to think about here except fixing the bug.  Just make sure that the release
notes make it very clear that this change has been made.  Of course, for those
following my suggestion in comment #3, any change in behavior will be entirely
inconsequential, as opposed to the recommendation that one set the base path to
null, which takes advantage of existing behavior, but doesn't hold up well if
behavior changes.


Jake

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message