Hanasaki JiJi wrote: > Thinking out loud here.... What do you think? > 1. turn the VFS providers into JNDI SPI > 2. implement VFS via JNDI or the JNDI SPI's directly
+1 Tomcat abstracts the file system using JNDI - it may be worth taking a look. That means any JNDI based VFS would be easy to plug into tomcat, and you can get some pretty well tested and optimized modules for .war and file system. You may also take a look at the caching and other optimizations that Remy put into the jndi layer. One of the big benefits of using JNDI as the API for the VFS is the stability of the API, and the huge number of people who are already familiar with it. A disadvantage is the greater complexity - even if you don't have to implement all JNDI methods, there is a bit more work. However Name and few other things allow some very interesting optimizations that are just imposible otherwise. If VFS switches to JNDI - it may be worth merging some of the code from tomcat. Costin > > Adam Murdoch wrote: >> On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote: >> >>>Any comparisons on VFS vs JNDI? seems very similar to me. >> >> >> They are very similar. JNDI is a little more general: a namespace of >> Objects. VFS is a little more specific: a hierarchy of files. >> >> VFS does not try to be as universal as JNDI does, even though there is >> going to be plenty of overlap (find by name, create, delete, get/set >> attribute, >> etc). VFS adds things that don't make sense under JNDI's more general >> model (get content as a stream, content signing, copy a tree, converting >> to/from java.io.File, etc), and does things in a way that reflects how >> files get used (as opposed to how generic namespaces of Objects get >> used). >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
