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=39548>. 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=39548 ------- Additional Comments From [EMAIL PROTECTED] 2006-05-13 14:29 ------- The hard coded locating strategy is surely a weakness of this library. Your patch is a step in the right direction. Over a year a ago we had a discussion about this topic on the developers mailing list. We all agreed that the current situation is not the optimum, but could not find a consensus about how a better solution would look like. Your implementation seems to be very similar to one of the suggestions made at that time. A different suggestion was to have a Locator interface like the following: public interface Locator { URL locate() throws ConfigurationException; } So that the parameters needed for locating the file (e.g. base path and file name) are not exposed in the interface, but are part of a specific implementation. File-based configurations would then have to be changed to have a new load() method, which accepts a Locator object. A client would load a configuration the following way: Locator loc = new URLLocator(<a URL>); config.load(loc); provided that URLLocator is an implementation of Locator. WDYT? -- 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]
