NIO file systems

[Benson Margulies]

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é]

Hi Benson,

I never had any issue with Paths but I used default FileSystemProviders.

Do you have a code snippet ?

Regards
JB

Post by Benson Margulies
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?

[Benson Margulies]

https://github.com/google/jimfs/issues/34

Post by Jean-Baptiste Onofré
Hi Benson,
I never had any issue with Paths but I used default FileSystemProviders.
Do you have a code snippet ?
Regards
JB

Post by Benson Margulies
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é
http://blog.nanthrax.net
Talend - http://www.talend.com

[Benson Margulies]

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;
}

Post by Benson Margulies
https://github.com/google/jimfs/issues/34

Post by Jean-Baptiste Onofré
Hi Benson,
I never had any issue with Paths but I used default FileSystemProviders.
Do you have a code snippet ?
Regards
JB

Post by Benson Margulies
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é
http://blog.nanthrax.net
Talend - http://www.talend.com