No, it's probably not a visibility issue. It has to do with class loaders and their "scope".
For example, if I were to create a singleton based on a class in a private package, its scope would be just the bundle containing it. If you would stick that same class in a different bundle (as part of a private package) it would create a second, completely separate singleton. In fact, you could argue if singleton would still be a correct name for this. ;) On the other hand, if you were to create a singleton based on a class in a public, shared package, there would indeed be one singleton for everybody using that package. However, when such a package is updated, you could still run into the case where some bundles are not refreshed and others are, causing two different "copies" of that package to be around (and therefore also two singletons). My advice: avoid "public" singletons. If you must use them inside private packages in a single bundle, that's fine, but remember their scope. For all new code, forget about singletons and start thinking about services (as has been recommended here by several people already). Greetings, Marcel On Feb 4, 2013, at 14:22 , John W Ross <[email protected]> wrote: > Isn't this simply a visibility issue? I would think that declaring your > static variable as volatile would allow everyone to see the updated value. > > John > > > > > Re: [osgi-dev] Static variable not so static after bundle update. > > > > 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 > > > > _______________________________________________ > 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
