On 2/21/2011 9:57 AM, Peter Kriens wrote:
Ok, I guess I figured it out :-) At least I hope.
The problem is that Equinox and Felix have been working together to make the
visibility of services workable in practice but forgot to update the spec. The
magic to make it work is to create a dummy bundle and use that for service
proxy registration. You only need one for all service proxies.
It turns out that both Equinox and Felix detect an "extender" by looking at the
implementation class of the Service Factory. If the Bundle Context does not corresponds
to the class loader of the Service Factory implementation then they assume you are an
extender and they always grant you visibility.
I have a couple of questions about this logic
1) Is this 'extender' notion part of the existing specification...or
it's just not been specified yet?
2) If a bundle can create, install, manage, etc a new bundle that
satisfies this extender condition...and then use it to register a
ServiceFactory, then why can't it simply register a ServiceFactory
directly? That is...why is it necessary to have an extender at all?
3) Which versions of Equinox and Felix have this extender logic...and is
it possible to do something that will work properly (or at least
tolerably) on older versions of the framework?
Otherwise, the original OSGi rules come into play that are much more restricted.
So by using a dummy bundle for your service registrations you tell Equinox and
Felix that you're an extender and they will give you some more leeway. An added
benefit is that this dummy bundle can also have no imports and exports so never
give you a problem with conflicting imports/exports.
I had thought from BJ's notes that imports (of the service type packages
+ versions) would be needed in the dummy bundle. Is that not correct?
More generally, what must this dummy bundle consist of? Finally...dummy
bundle creation code that satisfies the necessary extender bundle
conditions would be much appreciated (as I don't want to fumble around
with creating an extender that isn't structured as necessary, etc).
Thanks,
Scott
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
