Re: [osgi-dev] FileSystemProvider for OSGi bundle

2017-05-18 Thread Peter Kriens 
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  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://./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

Re: [osgi-dev] FileSystemProvider for OSGi bundle

2017-05-17 Thread Matt Sicker 
I've been using Reactor as well, mainly because it has better method names
and uses Java 8 functionality. I've also started using Monix in Scala which
is compliant with the same RS API standard. There's also vert.x which works
well in OSGi and supports the RS API, though it doesn't really provide a
nice DSL for using it (most things in it either use callbacks or have an
RxJava 1.x API).

On 17 May 2017 at 18:35, Simon Chemouil  wrote:

> Simon Spero a écrit le 18/05/2017 à 01:12 :
> > The   reactive-streams API is  provided by the nested interfaces in
> > jdk9s java.util.concurrent.Flow (Doug Lea original here
> >  jdk8/java/util/concurrent/Flow.java?view=markup>).
>
> It's been available for a while and as a valid OSGi bundle on maven
> Central [1] with several implementations. Doug Lea is not the author of
> the RS APIs, but as the lead for JEP 266 [2] he moved them into
> j.u.concurrent.
>
>
> > Of course, they aren't actual sub-types of the org.reactivestreams.*
> > classes, so wrap and delegate.
> > A basic-but-Doug-Lea push-stream with flow control is included in
> > java.util.concurrent.SubmissionPublisher
> >  jdk8/java/util/concurrent/SubmissionPublisher.java?
> revision=1.6=markup> ;
> > rxjava2  Flowable's are nicer.
>
> I use Reactor[3], which is inspired by RxJava but was built from the
> start with reactive streams and back-pressure in mind.
>
> Simon
>
>
> [1]
> http://search.maven.org/#artifactdetails%7Corg.reactivestreams%7Creactive-
> streams%7C1.0.0.final%7Cjar
> [2] http://openjdk.java.net/jeps/266
> [3] http://projectreactor.io/
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>



-- 
Matt Sicker 
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] FileSystemProvider for OSGi bundle

2017-05-17 Thread Simon Chemouil 
Simon Spero a écrit le 18/05/2017 à 01:12 :
> The   reactive-streams API is  provided by the nested interfaces in
> jdk9s java.util.concurrent.Flow (Doug Lea original here
> ).

It's been available for a while and as a valid OSGi bundle on maven
Central [1] with several implementations. Doug Lea is not the author of
the RS APIs, but as the lead for JEP 266 [2] he moved them into
j.u.concurrent.


> Of course, they aren't actual sub-types of the org.reactivestreams.*
> classes, so wrap and delegate. 
> A basic-but-Doug-Lea push-stream with flow control is included in
> java.util.concurrent.SubmissionPublisher
> 
>  ;
> rxjava2  Flowable's are nicer.

I use Reactor[3], which is inspired by RxJava but was built from the
start with reactive streams and back-pressure in mind.

Simon


[1]
http://search.maven.org/#artifactdetails%7Corg.reactivestreams%7Creactive-streams%7C1.0.0.final%7Cjar
[2] http://openjdk.java.net/jeps/266
[3] http://projectreactor.io/
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] FileSystemProvider for OSGi bundle

2017-05-17 Thread Achim Nierbeck 
Hi,

the pax - eco system (from ops4j) contains a bunch of little helpers,
either pax-swissbox or maybe pax-dir may help? [1]

regards, Achim

[1] - https://ops4j1.jira.com/wiki/display/paxurl/Dir+Protocol


2017-05-17 15:27 GMT+02:00 Thomas Watson :

> I'm not aware of such an implementation, but it may be interesting to see
> if such an implementation can be provided either by the framework or even
> better, by a bundle installed on top.  I have not looked at providing a
> FileSystemProvider before.  I assume it is similar to providing your own
> protocol handler for URL?
>
> Tom
>
>
>
>
> - Original message -
> From: Michael Lipp 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List 
> Cc:
> Subject: [osgi-dev] FileSystemProvider for OSGi bundle
> Date: Tue, May 16, 2017 4:40 PM
>
> 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...
>
>  - Michael
>
>
>
> ___
> 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
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] FileSystemProvider for OSGi bundle

2017-05-17 Thread Thomas Watson 
I'm not aware of such an implementation, but it may be interesting to see if such an implementation can be provided either by the framework or even better, by a bundle installed on top.  I have not looked at providing a FileSystemProvider before.  I assume it is similar to providing your own protocol handler for URL?
Tom 
 
 
- Original message -From: Michael Lipp Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: [osgi-dev] FileSystemProvider for OSGi bundleDate: Tue, May 16, 2017 4:40 PM 
Hi,I searched to no avail. Does anybody know of an implementation ofFileSystemProvider(https://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html)that supports the "bundle:" scheme (similar to the Zip File SystemProvider: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 availableas 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 withscheme "jar", which can be passed to FileSystems.newFileSystem. Whenrunning in the OSGi environment, I get a URI with the "bundle" scheme... - Michael___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev