right. the check for file:// is in repeated AvalonFileSystem (through calls to AvalonContextUtilities) anyway and does not neccessarily apply for other implementations of FileSystem.
If nobody objects, I will remove the repeated redundant checks. A side-effect is that failures no longer occur at configuration time with a ConfigurationException, but at file access time - that should generally be only be a few msecs later. On 9/17/07, Zsombor Gegesy (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/JAMES-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528030 > ] > > Zsombor Gegesy commented on JAMES-803: > -------------------------------------- > > The best would be omit the checking, and rethrow the exception which comes > from the 'FileSystem' implementation. > > > Add ability to load resources from the classpath instead of the file system > > --------------------------------------------------------------------------- > > > > Key: JAMES-803 > > URL: https://issues.apache.org/jira/browse/JAMES-803 > > Project: James > > Issue Type: Improvement > > Components: James Core > > Affects Versions: Trunk > > Reporter: Zsombor > > Assignee: Bernd Fondermann > > Priority: Minor > > Attachments: loading-from-the-classpath-spring.patch, > > loading-from-the-classpath.patch > > > > > > Currently lots of components try to get their configuration files from the > > filesystem, but most of the time it's simpler to get from the classpath. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > 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]
