Thoughts on OSGiFS

by kengilmer

I’ve spent some time working with the prototype implementation for a filesystem-based management interface to OSGi.  Some points that have become apparent:

  • It should probably be called something like “filesystem admin” or “native admin” to be more inline with the OSGi naming style.
  • I’m unable to find a way around the ‘one thread per file’ problem.  I was hoping there was some magical NIO thing, but if there is I can’t find it.  Due to this, I’m considering either using FUSE (which would limit it to Linux only) or consolidating what files are available in the interface to as few as possible.  The former has the possibility of a much richer user experience, but requires JNI integration with FUSE.  I have had little luck with with existing libraries for this on Linux.  The latter is less work but could end up making the whole thing more of a pain than it’s worth.
  • The logic of having directories for run levels, and symlinks in them that point to an install directory is a mixed bag.  It’s nice to have one directory where all the bundles go, and the runlevel convention is pretty simple, but having the management agent (osgifs) delete the symlinks when a bundle fails to start is not a good approach.  In general, osgifs should never delete files, it just causes user confusion.  So, there needs to be another way (via the filesystem metaphor) of defining runlevels for bundles, providing a clear view of state and handling cases of run level changes and bundle start failure.
  • The felix auto install feature is quite handy.  It’s nice to be able to just scp the jar to a remote, machine, run it, and have an OSGi framework ready to go.
  • The shell integration becomes quite natural.  And when combined with screen, tee, etc. it is a very nice way of running and managing remote OSGi framework instances.  Also, running a framework in the background of a running shell great for debugging, in that any log or stdout output from the framework is printed in the shell.  This gives you immediate feedback if something happens.
  • I should look into integrating with Karaf, but it seems like the first order of business would be dealing with the Maven dependencies, which is something I’ve never quite had the time to learn.

So, in summary I’d say the prototype is a “success” to the degree that I’m going to continue to use it, but it needs a lot of work before I’d consider it relevant and valuable in a larger scope.