On 6/20/06, Richard S. Hall <[EMAIL PROTECTED]> wrote:
I cannot say that I totally understand your solution.

Maybe I just too many words again :-)

* The Felix class has an instance field m_resourceFactory of type
OSGiResourceFactory which is assigned in the Felix.start() method.
* All resource accesses go through instance method
OSGiResourceFactory.createResource(String)
* A resource can also be acquired through OSGiResource.getChild(String relPath)

This solution has no static global - except the somewhat static global
in the property resolver.

In general, I try
to avoid the use of static globals since they decrease flexibility in

I absolutely agree. In fact the only static method (perhaps described
incorrectly is OSGiResourceFactory.createInstance(PropertyResolver)
which creates a factory from the configuration properties and which is
simply sort of a convenience method.

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.

This sounds promising and also allows me to solve yet another issue:
In my approach the storage has to be present outside the framework. If
I would be able to plugin into the creation of the BundleRevision
instance, this would be great as I could create a bundle which just
acquires the storage and provides functionality to access bundles in
that storage

I do not think hooking into the creation of the IContent instances is
a top priority, as those are created inside the BundleRevisions, right
?

But going that way, would probably also require touching the
BundleCache and BundleArchive classes, as they currenty are File
based. In fact the Felix.start method is documented to support a
felix.cache.class property which names the BundleCache class to use -
yet it seems to not be implemented like this.

Maybe to illustrate my solution, I will just provide the patch to the
mailing list in minute.

Regards
Felix

Reply via email to