Felix Meschberger wrote:
(1) Our product is running as a web application inside any customer
supplied servlet container (Tomcat, WebSphere, WebLogic, Caucho).
Also, we want to execute the product with as minimal OS filesystem
requirement as possible accessing code and content only from a JCR
repository. Unfortunately, out of the box, the Felix framework
requires an OS filesystem. Please find my proposal below.
Regarding Filesystems: I found, that direct filesystem access in the
current Felix project trunk is isolated in only few places.
Additionally, JAR files seem to be accessed through a JarFileX class,
which extends JarFile. So what I did to remove the reliance on the
filesystem, is to define a resource interface (I call it OSGiResource
laking a better name) and a resource factory abstract class (I call it
OSGiResourceFactory for the same reason). The factory provides a
static method to create resource instances from a string path or
location URL. The resource factory implementation to use is defined by
a configuration property. Resources are either created by calling the
resource factory method or creating the resource instance as child of
a another resource.
I cannot say that I totally understand your solution. In general, I try
to avoid the use of static globals since they decrease flexibility in
how Felix instances are created and embedded (e.g., some users embed
Felix inside of bundles, which themselves can have Felix inside of their
bundles).
In general, Felix has two abstractions that relate to the file system:
* org.apache.felix.framework.cache.BundleRevision - which represents
how bundles are saved in the bundle cache.
* org.apache.felix.module.IContent - which represents access to the
module content itself.
There are implementations of these interfaces for JarRevision and
JarContent (as well as others). Why is it not sufficient to create
different implementations of these interfaces to suit your needs? The
purpose of these abstractions is to be able to do what you ask (i.e.,
change storage approach), so if they are not sufficient for that, then
we should consider making it so. If the main thing is that there is no
external way to add and configure new implementations, then that is
something we could work on.
Of course, as a consequence of using a resource class instead of the
java.io.File class, the BundleContext.getDataFile(String) method might
return null, if the required bundle resource cannot be accessed in the
file system.
Not a problem, since the spec allows that.
I would be very interested in any feedback on this idea and whether
you would be interested in a patch.
We would definitely be interested in understanding what is need and
coming up with and/or adopting a solution for you.
Felix
This could get confusing... ;-)
-> richard
