Re: NIO file systems

[Benson Margulies <be...@basistech.com>]

Let me expand on the problem here. The code below insists on using the
system class loader to find all the providers via SPI.

So, putting a file system provider into an OSGi bundle shouldn't work
very well, right?

// loads all installed providers
private static List<FileSystemProvider> loadInstalledProviders() {
    List<FileSystemProvider> list = new ArrayList<FileSystemProvider>();

    ServiceLoader<FileSystemProvider> sl = ServiceLoader
        .load(FileSystemProvider.class, ClassLoader.getSystemClassLoader());

    // ServiceConfigurationError may be throw here
    for (FileSystemProvider provider: sl) {
        String scheme = provider.getScheme();

        // add to list if the provider is not "file" and isn't a duplicate
        if (!scheme.equalsIgnoreCase("file")) {
            boolean found = false;
            for (FileSystemProvider p: list) {
                if (p.getScheme().equalsIgnoreCase(scheme)) {
                    found = true;
                    break;
                }
            }
            if (!found) {
                list.add(provider);
            }
        }
    }
    return list;
}

On Mon, May 23, 2016 at 9:54 AM, Benson Margulies <be...@basistech.com> wrote:
> https://github.com/google/jimfs/issues/34
>
> On Sat, May 21, 2016 at 2:27 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi Benson,
>>
>> I never had any issue with Paths but I used default FileSystemProviders.
>>
>> Do you have a code snippet ?
>>
>> Regards
>> JB
>>
>>
>> On 05/20/2016 09:56 PM, Benson Margulies wrote:
>>>
>>> java.nio.file.Paths#get(URI) is another of these things that doesn't
>>> work so well in an OSGi environment. If a file system is registered
>>> via the SPI, the list of providers in the FileSystemProviders class
>>> ends up with references to classes in the system class loader, even if
>>> some of those providers 'live' in OSGi bundles.
>>>
>>> I didn't see a servicemix jar that in this department; has anyone
>>> considered creating one?
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com