Ferry, > Why would you want to keep the getInstance() pattern around when your bundle > registers a service? I don't. As I wrote in my initial email: "I am not necessarily looking for a solution because there is a better way to solve this problem, but I would like to understand exactly what is going here. I don't quite get it yet." :-)
> It's a classical java pattern that doesn't translate well to OSGi. > Your service can be easily injected into the consuming bundles. Thanks, that is what I had in mind as a 'better way...". > Keep in mind that your bundle can be loaded/running multiple times in OSGi, > so a static instance variable really has no meaning in that context Will keep that in mind. Thank you. Regards, Erwin > > On 03/02/13 21:59, Erwin Hogeweg wrote: >> >> *Erwin Hogeweg* >> Clare Controls, Inc. >> 7519 Pennsylvania Ave. >> Suite 104 >> Sarasota, FL 34243 >> (561) 306 7395 >> [email protected] <mailto:[email protected]> >> >> >> >> On Feb 3, 2013, at 3:15 PM, Neil Bartlett wrote: >> >>> >>> On Sun, Feb 3, 2013 at 8:05 PM, Erwin Hogeweg >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Neil, >>> >>> Thank for the quick reply. >>> >>>> You need to show where the getInstance() method is called. Since >>>> you don't call it from your start() or stop() method, I suspect >>>> you must be calling it from another bundle or a thread. >>> Correct, the getInstance() is called from another bundle through a >>> registered service. >>> >>> >>> Is the bundle exporting the service interface package, in addition to >>> registering the service instance? >> No, the API is in a separate bundle. >>> If so, the importing bundle will be fixed to that export until a >>> Refresh Packages operation is done. >> >>> >>> 1) Don't export the service interface package from the same bundle >>> that registers the service instance. For example have a third bundle >>> that only contains pure APIs, no implementation code. >> Checked. >> >>> 2) Refresh packages (use the "refresh" command from the Gogo shell). >>> This causes OSGi to recalculate the package wiring graph... now the >>> importing bundle can be rewiring to the new version of the export. >> Ah, that seems to do something. I need to uninstall the bundle first, >> than run refresh, and than install the bundle for something to happen. >> (running into another 'issue' now, but it seems to solve the initial >> problem so now I can sleep again...). >> >>> It's important to understand that package wirings in OSGi are *not* >>> particularly dynamic, because calculating them is an expensive >>> operation. After an update (or better, after a batched series of >>> updates/installs/uninstalls) you should call the refresh command to >>> indicate to OSGi that you have finished and it can now go ahead and >>> perform the rewiring. >> Thank, will keep that in mind. >> >> Thanks for the insight Neil, you help is appreciated. >> >> Kind Regards, >> >> Erwin >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > -- > Ferry Huberts _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
