[
https://issues.apache.org/jira/browse/VFS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16915882#comment-16915882
]
Michiel Hendriks commented on VFS-727:
--------------------------------------
Already ahead of you, wanted to create a ticket number to refer to. I created a
PR which fixes all but 1 location:
[https://github.com/apache/commons-vfs/pull/69]
Fixing HostFileNameParser is kind of trivial, except that it breaks the
following test case:
* org.apache.commons.vfs2.provider.test.GenericFileNameTestCase
* org.apache.commons.vfs2.provider.smb.test.FileNameTestCase
As they do not pass a context in the parseUri call, and I haven't figured out
the preferred way to pass a context in case of unit tests. Am I right that in
normal operation the context passed to parseUri cannot be null?
> Creation of singleton file system manager from providers
> --------------------------------------------------------
>
> Key: VFS-727
> URL: https://issues.apache.org/jira/browse/VFS-727
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.4.1
> Reporter: Michiel Hendriks
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A lot of file provides have a call to VFS.getManager() in their findFile(...)
> implemention, mostly to strip of the scheme.
> This is bad in two ways.
> 1) it creates a global FileSystemManager if it does not exist yet, and could
> result in an exception because not all default providers can be loaded (e.g.
> no commons http results in class not found exceptions). This obviously also
> introduces a global state.
> 2) the result of VFS.getManager().getSchemes() is not the same as the schemes
> registered in the file system manager that contains the registered provider.
> All calls to VFS.getManager().getSchemes() should be replaced by calls to
> getContext().getFileSystemManager().getSchemes()
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
