felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: Non-File based Framework
Date Tue, 20 Jun 2006 09:20:32 GMT
On 6/20/06, Richard S. Hall <heavy@ungoverned.org> 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

Mime
View raw message