you might want to look at the Equinox Adaptor Hook mechanism. Basically under Equinox is an "adaptor" layer that allows you to replace or hook into many of the implementation details of the framework (classloading, storage strategies, ...). Different framework fragment bundles can hook different parts of the adaptor and add or replace function. We use this, in particular, to completely change how bundles are laid out on disk (e.g., for Flash file systems vs normal file systems) adding caching etc. Seems relevant here.
Jeff "Felix Meschberger" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/20/2006 05:20 AM Please respond to [email protected] To [email protected] cc Subject Re: Non-File based Framework 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
