Hello Bokie,
On Nov 11, 2012, at 13:11 PM, bokie <[email protected]> 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:
manager.add(createComponent()
.setImplementation(WebResourceHandler.class)
.add(createBundleDependency()
.setStateMask(Bundle.ACTIVE)
.setFilter("(X-WebResources=*)")
.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: [email protected]
For additional commands, e-mail: [email protected]
