felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: DependencyManager - ResourceDependency
Date Sun, 11 Nov 2012 14:45:13 GMT
Hello Bokie,

On Nov 11, 2012, at 13:11 PM, bokie <jms.cercas@gmail.com> wrote:

> 1. If my ResourceProvider provides two resources; /res/file1 and /res/file2,
> the "added" callback of the impl class that I've defined as having a
> dependency on /res/file1 gets called twice even though I've
> setFilter("(path=/res/file1)") - seems like I'm not dealing properly with
> the filter mechanism somewhere.

The provider you implement should deal with the filter. I think the test case had some code
for that as well. The reason to let the provider deal with the filters is that the provider
should be capable of doing this in an optimal manner.

> 2. What would you suggest is the best policy to handle resources in a more
> "bundle private" manner - it seems that the DependencyManager -
> ResourceDependency is great for cases where you want to say: Hey, anyone
> who's interested in resource A, here you go, I'm providing it. 

There is a different design pattern you could use, the extender pattern. Let's say you have
bundles that have resources that are used for a very specific purpose (maybe they're exposed
via a web server). What you could do is define a new manifest header for these bundles, let's
call it:

X-WebResources: res/

Now, with the dependency manager, you could make a bundle that listens to all bundles that
have this header. You can use the bundle dependency for that:

		.setCallbacks("add", "remove")));

This will make a component that listens to all bundles that are ACTIVE (so if you stop a bundle
its resources will go away) and it will only consider bundles that have a manifest header
X-WebResources (the filter will work against the whole manifest, so you can filter on any
entries you like).

class WebResourceHandler {
	public void add(Bundle b) { ... }
	public void remove(Bundle b) { ... }

In the add/remove you would actually extract the resources from the bundle somehow and do
something useful with them.

If your resources are always in a bundle, this extender pattern is probably the easiest solution.
If the resources can be anywhere, the resource abstraction that the dependency manager offers
is the more flexible solution.

> 3. Is there another way of getting the BundleContext injected besides
> defining a field like this (perhaps method injection) that I am not aware
> of:
>    private volatile BundleContext context;

No, there currently only is field injection. You can however specify the name of the field,
should you have multiple fields of the type BundleContext.

Greetings, Marcel

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message