Did you look at the example code I put on github? The "dummy" bundle 
(bundleProxy in the example) can be completely empty. It just needs to be 
started to have a bundle context with which the proxy services are 
registered. You can also stop the bundle to unregister all the proxies.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Scott Lewis <[email protected]>
To:     [email protected]
Date:   2011/02/22 12:53
Subject:        Re: [osgi-dev] Classloader accessibility and 
ServiceTracker.open(true)
Sent by:        [email protected]



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

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to