[jboss-dev-forums] [Design of POJO Server] - Re: VFS issues

[adrian@jboss.org]

I've created an alternative version of the VFS prototype in
org.jboss.virtual
(I didn't want to break EJB3's usage of the org.jboss.vfs).

The main effort is to try to make it consistent
in how it creates virtual files rather having repeated 
(but inconsistent) code across the retrieval mechanism.

The org.jboss.virtual is a refactoring of org.jboss.vfs
(I left the original authors in place where relevant).

The other changes are:

1) A split into user wrappers and the real implementation.
User (api) -> Real (spi)
VFS -> VFSContext (old ReadOnlyVFS)
VirtualFile -> VirtualFileHandler (old VirtualFile)
The user api is made of concrete classes that delegate to the spi

The user api is in org.jboss.virtual, 
the spi is in org.jboss.virtual.spi

2) VFS also serves as the initial factory (wrapping the locator
with a simpler static api).

3) Abstract support for implementions, basically all you need
to implement is getting the root in the VFSContext
and then (besides the attributes) getChildren() and findChild()
in the VirtualFileHandler.
There is also some simple support for findChild based on
two models:

a) StructureVirtualFileHandler - which bumps through
each context of the path, i.e. com/acme/Blah
is effectively (but more efficiently) turned into 

  | start.findChild("com").findChild("acme").findChild("Blah");
  | 
This is what the file vfs does.

b) Simple - where all the entries are known to the root
this is what the jar stuff does.

You don't have to use either of these of course. :-)

4) A cleaner and more expressive query api based on the visitor
pattern. Other simpler queries in the api are wrappers for this.
The default visit impl is based on the getChildren() from the spi
so you don't need to write any of this yourself.

5) Paths work whether they end in a / or not
com/acme/directory/ == com/acme/directory
the only reason for an explicit slash is when you want to
express "contents of directory" rather than the directory,
which isn't relevant for this api.
There is isDirectory() if you need to know what type it is.

Things missing that are in org.jboss.vfs
1) Serialization of the VFS objects
2) Internal caching 
3) Support for "search context"
4) Nested jars are unpacked into temp files rather than
in memory byte buffers.

Finally, I've done a lot manual testing, but there is no
complete testsuite. I did port the original tests where relevant
and modified to the new api.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969706#3969706

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969706