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=34362>. 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=34362 ------- Additional Comments From [EMAIL PROTECTED] 2005-04-13 19:59 ------- WRT: Methods Yes they did cascade into one another.. but some contained code to set the base path. ect.. along the way. This created a disconnect in when and what some of the get/setters would return based on how you initialized/created the configuration. This is futher compounded by the fact that you can change the filename, basepath ect and it may not effect how the file is loaded / saved! The goal of my changes is two fold. I would like to fix the existing bug. But in doing so we are also forced to re-examine fields such as basePath. and how they are related to the actual configuration file. What I have come up with is something like this: Lets say you create a PropertiesConfiguration("/myDir/MyConfig.properties"); the base path would be /myDir/ the filename is MyConfig.properties if you save() the file will replace the existing file.(or create the file anew) if you save(String newName) a copy of the existing settings will be saved to newName but the existing configuration is unchanged if you setFileName( newName.props); the configuration will now use the new fileName from this point forward thus save() would now store to /myDir/newName.props The same applies to basePath. if you setBasePath("/newDir"); the new stored location is now /newDir/newName.props This logic must work weither the user is using URL / String or File to create / manipulate the configuration. So far.. ive got the changes almost complete. Im aware that what im doing here is more than just fixing the existing bug. And that prior to now these settings had no guarrenty of being in synch with where save() actually store data... but then if its not in synch.. what go are they? The only place i ran into a potential issue is for web based URLs.. ie http://www.myweb.com/myprops.props for this configuration basePath should not return http://www.myweb.com/ this is unconsitent as it means the base app now has to be smart enough to change the basePath to a URL. Instead I would add getURLBase and return null from getBasePath where getURLBase returns a URL for all implementation (including local files); but getBase.. im not sure.. so right now null if the URL is a remote url. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
