On 4/18/14, 11:47 AM, Siegfried Goeschl wrote: > Hi folks, > > so judging from the conversation we have volunteers for Apache Commons VFS :-) > > Reclaiming the message thread - who else would like to present his/her pet > component?
I would really love to attend, but at this point that is a fantasy. What I could contribute is the slides I did for ACNA on the v 2's of pool and dbcp [1]. I had to fly to get through this content and did not cover it all in detail, but I think it does make a decent 40 min talk + 10 min question slot. I would be happy to help patch / review slides / answer questions for a talk combining these. Phil [1] Should be available shortly on the ACNA conference site. For now, they are available on SlideShare at http://s.apache.org/Ih8. If anyone wants the ppt, just mail me directly. > > Thanks in advance > > Siegfried Goeschl > > > On 17 Apr 2014, at 17:28, Schalk Cronjé <ysb...@gmail.com> wrote: > >> On 17/04/2014 23:45, Mark Fortner wrote: >>> Schalk, >>> It's my understanding that new providers in NIO2 are simply added using the >>> ServiceLoader. >>> >>> Cheers, >>> >>> Mark >> Hi Mark, >> >> Maybe I should have explained better, >> >> In Apache VFS one can either add custom providers via a >> META-INF/vfs-providers.xml file (behaviour of StandardFileSystemManager). >> This means just compiling a JAR accordingly and have it available on the >> classpath. Let's call this Approach A. >> >> Alternatively one can call addProvider (on DefaultFileSystemManager) >> directly. This is quite useful in certain circumstances to do this >> programmatically. This is Approach B. >> >> With NIO2 loading occurs by providing a >> META-INF/services/java.nio.file.spi.FileSystemProvider file and >> ServiceLoader should take care of it. This is effectively the NIO2 way of >> Approach A. >> >> What I am saying is that I would like to have an Approach B for NIO2 as >> well, except that I have seen no clear way of accomplishing it. It could >> just be a lack of knowledge on my side. >> >>> >>> On Thu, Apr 17, 2014 at 3:31 PM, Schalk Cronj é <ysb...@gmail.com> wrote: >>> >>>> On 17/04/2014 22:38, Bernd Eckenfels wrote: >>>> >>>> <snip/> >>>> >>>> But theoretically both is possible: consume FileSystems as a provider >>>>> or implement an adapter which makes a VFS filesystem(manager) to >>>>> provide the FileSystem SPI. >>>>> >>>> I have been playing with that and it looks possible, but it is far from >>>> trivial. The meagre documentation or even lack of published success in >>>> writing NIO2 providers shows that this is a road less travelled. I have >>>> looked at the supplied ZIP example that comes with the JDK and IMHO still >>>> very much prototype code. >>>> >>>> I think VFS has some things going for it that I could not see in NIO2 - >>>> even something as simple as having two schemes for one provider. In >>>> addition, adding providers on the fly is easy in VFS, by just calling >>>> addProvider on FilesystemManager. From my initial investigation I could not >>>> see a clear way of doing the equivalent in NIO2. There will be more things >>>> like these, I am sure. >>>> >>>> I am very interesting in where this is going in future and the maintainer >>>> of Groovy VFS, I have a vested interest. I might be interested to go to >>>> Budapest in November if this gets discussed. >>>> >>>> <snip/> >>>> >>>> -- >>>> Schalk W. Cronjé >>>> @ysb33r >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> -- >> Schalk W. Cronjé >> @ysb33r >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
