Notice that the bundle: scheme is opaque. It is not standardised that it
follows the syntax as you showed, nor is it guaranteed to be a JAR. The only
thing guaranteed is the hierarchical nature of the path.
Since there is no way to get the directory listing from this URL there is no
good way to create a file system on it.
Kind regards,
Peter Kriens
> On 17 May 2017, at 20:55, Simon Chemouil <ecli...@mithrandir.net> wrote:
>
> Michael Lipp a écrit le 16/05/2017 à 23:39 :
>> Hi,
>>
>> I searched to no avail. Does anybody know of an implementation of
>> FileSystemProvider
>> (https://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html)
>> that supports the "bundle:" scheme (similar to the Zip File System
>> Provider:
>> https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html)?
>>
>> I have code that relies on a directory tree of resources to be available
>> as NIO FileSystem. This is no problem when the using the "ordinary"
>> class loading. The "root" is found using a resource lookup (URI resSrc =
>> this.getClass().getResource("").toURI();). This returns a URI with
>> scheme "jar", which can be passed to FileSystems.newFileSystem. When
>> running in the OSGi environment, I get a URI with the "bundle" scheme...
>
> Hi,
>
> I have searched before and did not find any. Here's a summary of my
> previous exploration on the topic:
>
> My conclusion is that there is no proper way to do it without being the
> system bundle. The thing is Nio Filesystems have non-blocking IO methods
> (eg AsynchronousFileChannels) and Bundles are opaque, might be stored in
> memory (e.g installing/updating a bundle from an InputStream). A partial
> solution for bundles only stored in disk is not reliable either, because
> the bundle "location" can be anything, and is rarely if ever an absolute
> path... recomposing an absolute path from the workingDir + the location
> might work in some cases, but that's super hackish. Then, the only way
> to work with them is blocking (reading a resource can only be done
> through URL#openStream())
>
> Blocking methods from the NIO filesystem provider could be implemented
> on top of those, but the non-blocking ones would have to be backed by a
> thread-pool, read extra bytes (it's possible with an
> AsyncFileChannel/RandomAccessFile to start reading at a random position)
> and in that case you might as well go for blocking methods and be "fake
> non-blocking" with your own thread-pool. Or they could throw
> UnsupportedOperationException, but that would probably break your
> consumer code, and it's a bit sad considering that's a big part of what
> Nio filesystems add to the File API!
>
> Because this probably requires a significant refactor of existing system
> bundles, my quick solution has been to lazily copy Bundle resources,
> when asked for, to the bundle storage area, and then use the regular
> filesystem API (since the bundle storage area is on disk). You can see
> how it's used there [1] (I happen to wrap it in reactive streams [2] for
> composition)
>
> Why go through all the trouble? First benefit is using nio.Files/Path
> API to abstract over different file-systems, another is to be able to
> have back-pressure with non-blocking consumers.
>
> The good news is, because those URLs are of the form
> bundle://<bundleId>.<bundleRevision>/resource, it does not need an
> update of the OSGi APIs, the system bundle can implement it, however as
> far as I know there are no implementation for open source frameworks,
> maybe there are on some proprietary ones ; and maybe it should be part
> of a future OSGi core spec, because that code is going to break on
> frameworks not implementing the extension!
>
> While it does not seem too hard to implement for bundles that stored on
> a file system (default filesystem provider), or as a jar file (zip
> filesystem), it is probably trickier for in memory-bundles: however
> there are existing open source in-memory filesystems like jimfs that
> could be used as a back-end, and the current Bundle IO/resource methods
> could wrap Jimfs newInputStream() calls.
>
> Hope this helps,
>
> Simon
>
> [1]
> https://github.com/primeval-io/primeval-codex/blob/master/src/test/java/io/primeval/codex/io/impl/ResourceFinderReaderImplTest.java
> [2] http://www.reactive-streams.org/
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
